Free Lessons
Courses
Seminars
TechHelp
Fast Tips
Templates
Topic Index
Forum
ABCD
 
Home   Courses   TechHelp   Forums   Help   Contact   Merch   Join   Order   Logon  
 
Back to Captain's Log    Comments List
Upload Images   @Reply   Bookmark    Link   Email   Next Unseen 
Access 2013 Web Apps - A Cautionary Tale
Richard Rost 
          
8 months ago
I ran across a throwback photo from my Facebook memories from Access Day Denver in October 2014. On the screen behind the presenter was the title "Lifecycle of an Access 2013 Web App." That moment captured Microsoft's big promise to bring Access into the cloud era by letting you take your database to the web. The presenter was Kevin Bell, an Access Team test engineer at the time, and the event was led by Armen Stein from J Street Technology. Armen has been an Access MVP since 2006 and still runs Access Day events. The last one I attended was last year in Redmond after the MVP Summit, and I believe he is doing another one again this year. They're awesome. Attend if you can.

With Access 2013, Microsoft promised to give developers a simple way to publish their databases online. The new Access Web App feature let you design tables, forms, filters, and views inside Access and then publish them to SharePoint. Once online, users could open the app in their web browser without needing the full Access client installed. Behind the scenes, the data lived in SQL Server, and all of the business logic was handled through macros instead of VBA. Forms were rendered as web pages through SharePoint and Access Services. It sounded great in theory: the power and speed of Access development, combined with the reach of the web, without having to learn HTML, JavaScript, or ASP. Microsoft said this was the future of Access, the next step in its evolution.

In practice, though, the concept had major limitations. You couldn't use VBA or any of the traditional Access form events that developers relied on. Everything had to be done with macros, which were harder to debug and much less flexible. Reporting was another major problem. If you wanted formatted reports or printable output, you had to export data to Excel or link the SQL tables back to a traditional desktop Access file. The web app itself had no reporting tools at all. The user interface was also restrictive. You were limited to whatever Access Services would render through the browser, which meant no custom controls, no dynamic layouts, and no advanced scripting. Even the performance was disappointing because every click had to travel through the server, which made the apps sluggish under real-world conditions.

Another problem was that the entire system depended on SharePoint with Access Services enabled. You either had to run SharePoint on-premises or use an older Office plan that still supported it. When Microsoft eventually shut down Access Services in Office, that effectively ended Access Web Apps. Even before that, most developers had already lost interest. Losing VBA, form control, and flexibility made the web apps feel like a downgrade rather than an upgrade, and very few organizations adopted them.

By 2017, Microsoft had quietly shifted its attention elsewhere. Access Web Apps stopped receiving updates, and the company began promoting PowerApps, Flow, and the broader Power Platform as the new way to build cloud-based business apps. By 2020, Access Services was completely shut down in Office 365. Technically, on-prem SharePoint servers can still host Access Web Apps today, but even Microsoft discourages that approach. The product is dead. (1)

That said, some value remains. If you still have an old Access Web App, the data backend is SQL Server, which means you can link them back into a normal Access front end. Doing that restores all the power of VBA, forms, and reports that made Access great in the first place. In other words, the web app itself might be gone, but the data does not have to be.

When I put out feelers and ask people what new feature they most want to see in Access, the number one answer is almost always the same: they want to put their Access apps on the web. They want to build their database just like they always have, complete with forms, reports, and VBA logic, but then click a button and publish it to the web. Getting your tables into SQL Server is easy enough, and I even have a seminar that teaches you how to do that. The hard part is the front end. Access is the ultimate rapid-development environment for forms and user interfaces, and nothing else has really replaced it.

If someone could create a tool that preserves that same Access experience but makes it truly web-based, that would be a killer app. What do you think?

LLAP
RR

(1) And if I had a nickel every time I got an email or saw a post online from people who think that Microsoft killing Web Apps meant that they were killing Access, I could buy myself a really expensive steak dinner.
Richard Rost OP  @Reply  
          
8 months ago

Kevin Yip  @Reply  
     
8 months ago
In Visual Studio, you can use VB.Net to create either a desktop app or a web app.  So you can conceivably re-use lots of VB code when you convert a desktop app to a web app.  But there would still be substantial re-coding to be done due to the many differences in user interface, object models, event-handling, the overall flow of operations, additional coding environments (HTML, CSS, etc.), etc., between desktop and web environments.  The re-coding may be substantial enough to make it a consultant-level job in most cases.

One way to avoid having to convert is to create a web interface that can be used locally and on the web.  When everything is done on web interface, there is nothing to convert.  The downside is not being able to use desktop-style user interface, which some users prefer.  But if you have a business to run, giving up some style points may be a small price to pay for not having to do potentially expensive web conversion in the future.
Kevin Yip  @Reply  
     
8 months ago
Below are my calculator apps, done for Windows desktop and for web.  Other than manually designing the UI for each, I didn't have to do much re-coding, as most of the code was copied and pasted from one to the other.  This is how a language can be "portable."  Almost all the popular languages like javascript, C++, python, etc., are portable.  VBA, sadly, is not, and can only be used in Office apps.  Portability is usually how multi-platform development is done, not the type of magical conversion Access web app tried to be.  When I first heard of Access web app, I immediately felt it was too good to be true.  Maybe AI could do it in the future.
Kevin Yip  @Reply  
     
8 months ago

Kevin Yip  @Reply  
     
8 months ago

This thread is now CLOSED. If you wish to comment, start a NEW discussion in Captain's Log.
 

Next Unseen

 
New Feature: Comment Live View
 
 

The following is a paid advertisement
Computer Learning Zone is not responsible for any content shown or offers made by these ads.
 

Learn
 
Access - index
Excel - index
Word - index
Windows - index
PowerPoint - index
Photoshop - index
Visual Basic - index
ASP - index
Seminars
More...
Customers
 
Login
My Account
My Courses
Lost Password
Memberships
Student Databases
Change Email
Info
 
Latest News
New Releases
User Forums
Topic Glossary
Tips & Tricks
Search The Site
Code Vault
Collapse Menus
Help
 
Customer Support
Web Site Tour
FAQs
TechHelp
Consulting Services
About
 
Background
Testimonials
Jobs
Affiliate Program
Richard Rost
Free Lessons
Mailing List
PCResale.NET
Order
 
Video Tutorials
Handbooks
Memberships
Learning Connection
Idiot's Guide to Excel
Volume Discounts
Payment Info
Shipping
Terms of Sale
Contact
 
Contact Info
Support Policy
Mailing Address
Phone Number
Fax Number
Course Survey
Email Richard
[email protected]
Blog RSS Feed    YouTube Channel

LinkedIn
Copyright 2026 by Computer Learning Zone, Amicron, and Richard Rost. All Rights Reserved. Current Time: 6/17/2026 7:38:38 AM. PLT: 1s