Future of Access

[Cotswold]

Back in the day I thought Filemaker was a bit noddy when compared to Access.
Looked promising but generally disappointed as a viable solution.
Maybe it has improved?

 

[CompSMART]

Back in my first semester of grad school, one of my professors gave me a copy of Access and asked me to load it on my computer and see if I could take some data he had in spreadsheets, import the data into Access, manipulate and report on the data. It's very hard for me to grasp the reality of that being 33 years ago and that I've been working with Access (either FT or PT) ever since. I've been hearing of Access' demise for almost that entire 33 years too (ha-ha). Microsoft can do whatever it wants with Access - but it would be very difficult for Microsoft to ignore the fact that the number of applications developed in Access over the course of 33 years is probably deep in the millions - with some portion of those still in use - and a significant portion of those in use considered mission critical by the organizations using them.

 

[The_Doc_Man]

Microsoft can and will do as they damned well please. However, there is a certain imprimatur to having a database product as part of Office. What usually happens with the other big companies is that at some point they have a product that they feel is dragging them down, so they spin it off to be on its own or as part of a limited subsidiary. If some day we hear that Access is going its separate way from the rest of office, I would be sad but not at all surprised. On the other hand, if Microdumb doesn't allow for a cadre of rogue software engineers to take over the spin-off, I would be terribly surprised.

 

[AccessBlaster]

I don't think Access will breakaway from Office because vba is the glue that holds all the Office tools together. However, if MS decides to deprecate vba and just go with Online Office, which currently includes Excel, Word, and Outlook, then Desktop Access will be on its own.

Excel/Outlook = actively invested, future-proofed.
PowerApps/Dataverse = where Microsoft wants people to go next.
Access = maintained, but sidelined.

 

[AccessBlaster]

Clipchamp probably gets more advertising dollars than Access, just sayin.

 

[AccessBlaster]

Access is basically in legacy mode

 

[AHeyne]

Also, and most importantly, the SQL Server team thinks of Access as a competitor because they don't even know what Access is and they think of it only in terms of Jet/ACE. So they don't even understand that many production Access applications rely on SQL Server or other RDBMS as their data store.

Do you really think they are so short-sighted and superficial?

Is that more your personal perception of the situation, or where do these statements originate from?

 

[GPGeorge]

MS may want Access users to migrate to PA, but if PA cannot fulfill all the needs their Access apps currently delivers. Therefore, users will continue using Access, as several have been doing for decades. MS is concerned about vba being a high security risk. That's why they wanted to retire desktop Outlook.

Fixed it for you.

 

[AccessBlaster]

True, but without web connectivity Access became a relic frozen in time. It was no longer growing and expanding, hence SQL.

 

[GPGeorge]

I said "if PA cannot fulfill..." because PA is young, Work In Progress, and may some day be as robust as Access, unless you know something we don't?

I remember you recently mimicking Access NW2 functionality with PA by making SQL Server Stored Procedures do the heavy lifting.

It's too bad we didn't have faith in Access Web Apps. By now it would've been robust and a viable Online Office tool.

How many years did it take for Access to become robust enough for developing complex applications?... Access 2.0 (1992) to Access 97?

While I was being tongue in cheek, I'm pretty well convinced that PowerApps simply can't compete on an equal footing with Access. You note that I resorted to SQL Server Stored procedures to get the functionality needed to replicate Northwind Developer. There's a good reason for that. The basic logic required even for the basic inventory management model in NW Dev would be a hard slog in PowerApps.

Other functions, like basic reporting, simply don't exist in the PowerApps environment. One can convert screens (think Access forms as the closest comparison) to PDFs. That's not close to the power and flexibility of an Access report.

Don't get me wrong. I think PowerApps will eventually be quite useful, particularly in a hybrid application where it can handle remote and off-site data entry tasks on a smart device. I think the primary barrier to PowerApps is the licensing model, which is geared to large institutional environments, not the typical applications which are the bread-and-butter of Access.

 

[AHeyne]

Your question is a bit snarky...

However, that was not the intention; it was meant purely objectively.

Thanks for your explanation.

 

[cedar]

Also, someone mentioned that power apps are "young", but they've been around now for 7 years...

 

[cedar]

bluespruce you almost have to be right about that. I don't pay attention to it regularly, and it's been a few years now. But I think if it was maturing into anything like the versatility of Access I'd/we'd have heard about it. From day one, Lightswitch was much closer to what an Access dev would look for, Beth Massi was a world class resource, but Microsoft folded it so casually.

 

[cedar]

IIRC, LightSwitch replaced SilverLight, and positioned it as an LOB RAD tool, but it didn't gain much traction, and MS replaced it with PowerApps. Is PA similar to LightSwitch?

I thought AWA's was a viable solution because it mimicked how we create tables, queries, forms, and reports in Desktop Access. It essentially had the same client UI. Access developers had high expectations that it would have a VBA_like language, but instead relied on event based Data Macros and was lacking the rich functionality available with VBA. So only a handful of Access developers adopted AWA and MS retired it in 2017.

So here we are again, for the 4th time, in the same dilema. First it was "Data Access Pages", then came "Access Web Databases", "Access Web Apps", and now "PowerApps". Next up, "PowerAI". . . "Hey AI, build me a web app with PowerApps that works just like Desktop Access NorthWinds2 application."

Your ending bit, not really re PA, because PA is not at all tied to Access. The other in your list were like that. Now Access has nothing to do with web depolyment.

I thing PA is much less like the Access model than Lightswitch was. Lightswitch was alive for about 5 years and evolved well in that time. As I understand it, Microsoft abandoned it not due to lack of popularity, but because some patent trolls sued them or threatened to around some part of the underlying tech. It still feels nuts that Microsoft let it dry up for that reason.

 

[GPGeorge]

Spoiler:

IIRC, LightSwitch replaced SilverLight, and positioned it as an LOB RAD tool, but it didn't gain much traction, and MS replaced it with PowerApps. Is PA similar to LightSwitch?

I thought AWA's was a viable solution because it mimicked how we create tables, queries, forms, and reports in Desktop Access. It essentially had the same client UI. Access developers had high expectations that it would have a VBA_like language, but instead relied on event based Data Macros and was lacking the rich functionality available with VBA. So only a handful of Access developers adopted AWA and MS retired it in 2017.

So here we are again, for the 4th time, in the same dilema. First it was "Data Access Pages", then came "Access Web Databases", "Access Web Apps", and now "PowerApps". Next up, "PowerAI". . . "Hey AI, build me a web app with PowerApps that works just like Desktop Access NorthWinds2 application."

Since MS has repeatedly failed to deliver a web based version of Access that gains traction with the Access development community, why don't we as a collective put together a white paper and present it to Microsoft? I would think we can come to a consensus on a good design for an Access Web version. We could define a library of RestAPI's that mimicks vba functionality and create a framework that includes an IDE and designer wizards similar to what desktop Access has. I've been following Wayne Phillips' TwinBasic project, but it's not web based, rather vba/vb6 compatibility for desktops: https://marketplace.visualstudio.com/items?itemName=twinbasic.twinbasic

10 years too late, I'm afraid. And, to be very blunt, a project that is quite unlikely to blossom due to lack of a coherent guiding plan and leader.

I'm not being critical of anyone at all. To the contrary, I admire the ambition.

What I'm suggesting is that Wayne Phillips' TwinBasic is the result of one person's vision, drive and commitment to a long-term project with a goal of creating a revenue stream. And I dare say that last bit is also crucial. Without a hope of return, such a project will languish,even after a brilliant start.

I do not want to be argumentative. What I question is not the concept itself, but the framework in which it is proposed:

A loosely defined collective of like-minded developers attempting to replicate -- for free -- everything that Microsoft spent millions of dollars building with a dedicated team of software engineers under the guidance of some really brilliant leaders.

It would be truly magnificent if it could be done. Again, I'm not questioning that. What I'm wondering is where the leadership and resources would come from and who would be able to dedicate the time and effort required while earning a living in their full-time job.

Address that organizational problem, and then we'll have some confidence it can happen.

 

[Steve R.]

Since MS has repeatedly failed to deliver a web based version of Access that gains traction with the Access development community, why don't we as a collective put together a white paper and present it to Microsoft? I

MS Access has its niche and like Cobol will continue to limp along. Nevertheless we need to recognize that technology evolves. Land lines and FAX machines are a dying technology. To a degree what we need to do is think-of-of-the-box and declare "independence" from Microsoft. What that implies is ditching the Microsoft environment. (This will also save $$$ as no licensing fees would be normally required.) Once that is accomplished open source databases can be used to deliver web based solutions to the user communities served by MS Access. If fact, this forum has precursor sub-forums, such as "Web Design and Development" that could be expanded to promote and achieve such a transition.

10 years too late, I'm afraid. And, to be very blunt, a project that is quite unlikely to blossom due to lack of a coherent guiding plan and leader.

@GPGeorge: Made a very observant call, that attempting to implement a a web based version of MS Access would be very challenging. This concern can be eventually overcome as people learn that there are other database solutions to MS Access that also free the users from the Microsoft environment. It will take time.

PS: Think of industry leaders such a Sears that have gone bankrupt or Intel which recently imploded. Anybody remember AOL? Industry leaders, such as Microsoft, tend to be very large and bureaucratic, eventfully they sputter. The users may then find that they are left out in the cold. With that in mind, people need to have a plan "B".

 

[GPGeorge]

"mimic" doesn't cut it. If your existing Access app cannot be directly converted, the pretend Access AWA is useless and that was what the public ruled.

That's because of their pricing model. It is not geared for small businesses. It is too expensive. Therefore, it is not a replacement for Access.

Again with the "mimic". If the "new" tool "mimics" Access but does not provide a direct conversion path, it will not be accepted. If companies are going to invest the time and money to completely recreate their Access apps, they can do it today with any number of tools available. VBA doesn't run on the web and therefore none of the code in the app is convertible. There is no getting around this conversion issue. Rewrites are expensive. PERIOD. Simply calling a tool "Access" doesn't make it so. That is the lesson you should learn from Microsoft's three (or maybe four) failures.

In the past, I've tried to make the point that adding a web-based component to an Access solution is not the same as replacing the Access solution with a web-based solution. One of the many reasons Access has never been recreated for the Web is precisely that. You don't need to duplicate the solution to be successful. You only need to provide components that are a) compatible with the primary solution, i.e. the Access database application and b) sompatible with remote data entry and/or reporting. In the past, I think an overabundance of optimism led too many people to see AWA's as the path to get around Access, not as a way to enhance it. It became an all or nothing proposition that was doomed for that reason.

Hybrid applications, on the other hand, should be cohesive across platforms, but they do not need to be duplicative to be useful.

I've spent several months working on a PowerApps vesion of Northwind Developer and documenting the process in videos on YouTube. In only one of those videos have I addressed interface differences deriving from the different design principles. Most of those videos document managing data for the unbound, stateless web environment.

I have concluded two main things, and a lot of little things.

1. PowerApps is far more capable than some would like to have you believe. I compare that to the oft-repeated complaint that SQL Server DBAs dismiss Access as too basic to be useful. At the risk of offending some, I think that is largely an artifact of not having spent much time examining the possibilities.
2. PowerApps is not a competitor with Access and probably never will be. Reporting is one glaring hole. Complex logic in reusable, modular code is another.

To sum up. I strongly believe that PowerApps interfaces for the mobile environment can be a strong candidate for a complementary partnership with Access interfaces for the desktop environment. I don't even think PowerApps is primarily a browser-based play for such hybrids. If you need a full-blown web app, build that.

 

[AccessBlaster]

It's almost like nobody saw this new fangled interwebs thing coming.

 

[CJ_London]

You can't expect MS to continue providing things for free, we've been spoiled in that aspect.

In terms of developing- how is it free? You either pay for a lifetime licence or by subscription. As far as free runtime is concerned, how much do you pay for a browser?

 

[GPGeorge]

What is this obsession with running in a browser? You don't need Access to run in a browser. You only need Access to be able to effectively connect to data sources across a WAN the same way that web apps do. Access is perfectly capable of doing this NOW. The issue is the connection is so slow it is like watching paint dry.

WHY do you think people should be willing to give up all the things that Access does and which a web app can never do? What is wrong with simply fixing the ONE limitation Access has and that is the speed of the connection to the remote database? I'm not saying this is a trivial problem to solve but in the greater scheme of things it is a pretty focused task and so maybe someone can figure out how to do it.

Yes, distribution of updates is easier with a browser but somehow those of us who create professional level Access apps manage to make this happen without disruption for our clients.

I agree. The obsession of running in a browser is, in my opinion, somewhat of a side issue.

That focus remains on an either/or choice and that is a false choice.

Back in 2008 or 2009, I was part of a development team. We were a couple of Access developers and a web developer. I created the Access interface and the web developer created the web interface. The other Access developer provided support from time to time.

The back end was cloud based so that both interfaces could share the data. At the time, we didn't have a way to host the website internally, so it was on a web host.

The key design pattern was that the Access interface did

• all of the ETL for test results from test equipment
• heavy data manipulation and aggregation of those test results
• other management tasks, such as maintaining client records and some information related to billing for test services

The web interface provided

• anonymous public access (there's that sneaky word in its other meaning) to the aggregated data
• a password protected way for clients to request testing on their equipment.

Two related, highly correlated, but fundamentally different kinds of processes built on the appropriate platforms.

That has colored my thinking about this kind of application ever since.

I simply can't rationalize wanting to "replace" Access to gain the benefits of remote interactions anonymous or not.

I can rationalize complementing an onsite solution with a more appropriately designed remote solution.

Now that PowerApps is available, I see it primarily as the extension of that same hybrid design onto smart devices: phones and tablets.