Future of Access

[CJ_London]

I could be wrong but I think the only device based db RAD tool that works on iOS is Filemaker.

As an individual you do have a choice, but the corporate world (with perhaps the exception of those who are into publishing/design/etc) choose windows because of the cost of equipment - iOS devices are around twice the cost of a windows equivalent.

One day, I expect everything will be on the web and devices merely dumb terminals - effectively back to the old main/mini computer era but without wires and no doubt less secure.

 

[GPGeorge]

There's also Realm, which I've never heard of before, and Firebase, but I don't think they're RAD like FileMaker.

Agreed. In the corporate world I am seeing more thin client workstations replacing desktops, and the consumer world is quickly heading in that direction. I wouldn't be surprised if the next major release of Windows and Office are SaaS Online versions and desktop perpetual versions are no more. A move like that would leave desktop Access out of the future, unless MS provides a viable online replacement. And I don't think PowerApps is it. AWA was actually a viable replacement, and by now would've been robust had MS not retired it.

PowerApps is currently more flexible and extensible than AWA's ever were. Granted that doesn't make them a viable replacement for AWA's either, but AWA's were doomed from the beginning by the box they were put in to begin with. The train went from Station A to Station B and stopped there. PowerApps has the Power Platform ecosystem behind it including the ability to consume Public APIs and connectors to over 300 different data sources, not just SQL Azure, as was the case for AWAs.

It's interesting to speculate what AWA's could have evolved into, perhaps something more like PowerApps already is, though?

One thing that tickles me is that PA was originally touted as a "low-code" platform. Yet over time that has evolved into "less low" coding. Today, for example, I saw a YouTube video on creating UDF's for PowerApps. They walk and quack a lot like simple VBA Functions, taking input parameters and returning output parameters OR executing actions like VBA Subs. What that tells me is that the Power Platform development team recognizes the need to push their platform beyond its early "no-code/low-code" identity.

Again, that could have happened with AWAs, of course. What did happen was a new platform was built from the ground up to be browser based from the beginning.

If it were not so costly to license, I'm convinced PowerApps would be a more popular option.

 

[CJ_London]

If it were not so costly to license

Precisely

 

[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.