Future of Access

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

 

[BlueSpruce]

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.

I put PA at the end because that's what MS wants Access users to migrate to, but I can tell that's not going to happen. MS needs to come up with a better tool that's affordable if they want the millions of Access users to convert. As @arnelgp says, "forever waiting, waiting for jellybean!".

 

[BlueSpruce]

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.

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

 

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

 

[BlueSpruce]

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

Are you thinking of a utility that converts vba code to a web development language? A desktop Access app cannot be entirely converted to a web app. I think a web app can reproduce to a certain extent Access vba functionality, such as executing event driven code and support vba_like built in functions,. However, web apps operate as stateless unbound objects and it's not going to let you manipulate filesystem objects, automate other desktop applications, or directly interact with Windows. Some basic functionality, like uploading/downloading files, creating pdf's, and sending emails are available. what Access really needs to evolve to is to support hybrid applications, where desktop Access clients can reliably work with remote backends.

 

[AccessBlaster]

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

 

[BlueSpruce]

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.

Perhaps we could submit a white paper to MS that provides a market analysis of current Access applications, a product plan, positioning, pricing, and sales projections? I bet if MS would've charged a minimal amount for desktop Access runtimes, users would've still paid for them. You can't expect MS to continue providing things for free, we've been spoiled in that aspect.

 

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

 

[BlueSpruce]

there is huge pressure to not use Access and for all the wrong reasons. But somehow creating seriously flawed spreadsheets doesn't seem to bother the It folks.

Who started that mentality, Corporate IT's, MS SQL Server marketing, or their DotNet folks?

 

[CJ_London]

The issue with large corporates is budget - I’ve provided many apps to service perhaps 3 or 4 employees who need a solution now, not two years down the line at a high cost. Wouldn’t be a problem if the large corporate systems provided the detail actually required, but the cost of modifying the system to do so is too high.

Large corporate systems are not designed to meet the strategic needs of their clients

 

[BlueSpruce]

I think the problem of Access FE's working seamlessly with remote db's is that Access is file server based and uses the SMB communications protocol, which doesn't handle delays and interference well. Access architecture also involves a lot of network traffic often having to load entire tables from the BE to the FE. I have seen some optimized Access/Azure apps, but was still slow, even without using vpn connections.

It's a lot different when an unbound web app does async gets and puts to a remote db, versus a bound desktop client that requires a persistent connection that's volatile when delays and noise easily break that connection. Then odbc often has to re-establish the connection.

 

[BlueSpruce]

Only a poorly designed query would require Access to request entire tables from the server. Access does its best to make every query a pass-through query. The fact that Access has to touch the query at all makes even good queries slightly slower than true pass-through queries but not enough so most people would notice or convince you to give up updateability for the sake of such a tiny speed increase.

I think the issue lies with how well odbc can translate queries before they're executed on the db server. One would think a PT query runs on the server exactly as it was written and stored in the Access FE, but odbc has mysterious ways of changing it, especially if it's a complex query with several joins. It's better to use server side stored procedures and let the server do the heavy lifting. Then what about all the server side lookup tables the combo boxes in Access forms needs to load?

 

[cedar]

Very interesting conversation.

A question that came up, how did the slant against Access take root in corporate IT departments, of course has several sides to it. One I think was mentioned, that IT folk aren't experienced with Access, never understand it's strengths, but do trip over it's weaknesses; and of course Access is not great for collaboarative development. But another reason is kind of paradoxical. There was a massive proliferation of small to medium sized Access projects in organizations precisely because they were so much easier and quicker to build, and typically didn't cost and arm and a leg.

Later edit: and the multiplicity of access dbs were unmanaged, often out of date, often had taps into data sources that with various permissions that could cause issues, and were often abandoned or hard to determine if they were still relevant or not. From that perspective, it's easy to see why many in IT would wish Access had never been introduced to their org.

 

[BlueSpruce]

Later edit: and the multiplicity of access dbs were unmanaged, often out of date, often had taps into data sources that with various permissions that could cause issues, and were often abandoned or hard to determine if they were still relevant or not. From that perspective, it's easy to see why many in IT would wish Access had never been introduced to their org.

IT also doesn't understand that it is in their best interest to provide in-house Access development support to help to ensure that users who attempt to go it alone create something sort of sound instead of crap.

So why did IT's ignore those Access apps when they could've managed them from the beginning, or at least enforced a policy? But wait a minute, all enterprise editions of Office included Access. So why single out Access when Excel also has hooks into corporate data sources, and is actually less secure than Access? Have IT's been pressuring MS to no longer include Access in M365 Enterprise editions?

BTW, this is the first thread I posted when I joined AWF. I feel it's an important topic to discuss. How can we influence Microsoft regarding the Future of Access? Can we make a difference?

 

[cedar]

They're not trained that way. They tend to go top down - "We're an Oracle shop." The end users that we often deal with do not seem to be who they work for; they work for whomever is higher up in IT. The higher ups in IT are even more remote from the end users.

Meanwhile the poor end users that actually get the work done for the org are being barraged by tasks and projects and often a sense that their data operations could be handled a lot better. Knowing that IT doesn't care that much, is overloaded, and slow, they often resorted to creating their own Access db, then when it gets too complex, they hire us; or they hire us from day one, often slipping in the engagement under the radar.

At least that's how it was in the 90s until maybe this decade. I'm not sure that this scenario is so common now. But it did result in hundreds of mystery databases scattered all over the place that no one who was supposed to be in charge of the data knew about. Yeah so they didn't like that.

Of course it could have made a lot of sense to recognize the reality (that end users were desperate enough to undertake stealth databases) and either helped out or facilitated or something. But probably the most common reaction was the urge to shut them down. Since they often couldn't (line of business dbs are useful!), it became a sore spot.

You'd think that a team (the company's inmates) could do better than that. But it's kind of like one of the other conundrums we see. IT folk tend to think they are way smarter than the end users (present company excluded), and often their bosses as well; but to many of the folks outside of IT, IT barely registers, and the help they provide seems more like finger in the dike than making things a lot better. I am sure that many/most/all of the people here have high regard for end users, but not everyone in IT or management does. Maybe that too is a part of why Access can be looked down on - anyone with interest can build something useful. Doesn't sound very elite!

 

[Uncle Gizmo]

So why single out Access

Luke chung spoke about this when he visited the UK the Microsoft campus in reading Berkshire...

I went up to see him present..

I mentioned it in this thread here:-

I need some artillery against Access haters

Hey all, i need some artillery to throw back at some corporate IT folks who hate Access and was hoping to get some of the wonderful experts in this forum's opionions. i'm developing a small application in Access to basically turn a large document into a electronic version with some other...

www.access-programmers.co.uk

What I didn't mention was that one of the reasons Luke mentioned that organizations do not like Microsoft Access is because most people can use it and create something that works... Unfortunately most people create something that is an abomination that works for a time and then stops... Then they take it to the server team --- I want it sorted out! This really pisses the server team off so instead of learning how to use access or get someone like one of us in that knows how to use access they scupper it every way they can... So it's politics! The problem for the server team is often the person creating the wayward database is the boss himself, so there's a sort of tolerance, tolerances the wrong word but you get my drift!

I forgot to mention this was about 20 years ago!

 

[BlueSpruce]

So why single out Access?

Is it because Excel is so overwhelmingly popular, and data stored in corporate db's cannot be updated with Excel? I have seen many businesses and corporate departments running their operations with Excel, but God forbid they create siloed db's with Access!