Access as front end for sharepoint web application

Where can I find information on creating a web based application that can use Access as a front end?  Access used to have data access pages for this purpose, then took that away and pushed sharepoint.  Now Microsoft is giving up on sharepoint pushing iot to godaddy.  I am trying to build a database driven application without relying on PHP if possible.  I want to use Acces for rapid development of user forms for a web application.  Help?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jeffrey CoachmanMIS LiasonCommented:
This can be done, ...but it is far from "simple", ...if you are new to database design or web design.
A great many Access devs have skipped the whole Shraepoint web database route, ...and have simply opted for using a .net programming platform. (Or PHP, al)

For all the hype, is still not clear what direction MS wants to move MS Access into.
Web dadabases are so for removed from desktop databases. (No vba code, different table design, learning new connection and web technologies, deployment, security, scalability, licensing fees ...etc...)

To be clear, is not as simple as you might expect to simply "make" an Access database and "put it on the web"

 In the recent past, ...more than a few posts here on sharepoint/access have seemed to languish,
Things may be different now, however...

There are other Experts here that know more about Sharepoint/web databases than I do, so lets here form them as well...


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Data Access Pages were nothing more than HTML and VBScript front ends to your data. You can easily recreate that sort of environment if you want, but they were very, very limited, and MSFT gave up on them almost immediately.

PHP is not your only option in regard to web development, although it's certainly one of the most popular. There's also ASP.NET, which might be easier to work with if you're familiar with VBA and such. There's plenty more too - Java, Perl, C, C++, Python ... the list goes on.

Access 2013 introduced the concept of Web Applications to Access. These are run entirely in a browser (you can use Firefox, Chrome, etc to run them), and are hosted on a Sharepoint site. The user knows nothing about this - they just open their browser and run the application.

Web apps are still in their infancy, and therefore have limitations. You cannot use VBA - everything is macro driven - so you might find functionality is lacking in a web app. In general, anything other than a somewhat simplistic add/update/delete sort of application may be beyond the capabilities of a web app.

There are "hybrid" apps, where you develop a desktop application and link the tables to an Azure database (a SQL Server database hosted "in the cloud"). These are typical desktop databases, with all the bells and whistles you're accustomed to. They do have some issue, most notably that they depend on a connection via your internet connection, which is inherently flaky. While web browsers have been developed specifically to deal with that flakiness, Access does not handle it well, and this can often be a very frustrating experience. Most have reported poor-to-mediocre performance with this sort of setup.

If your intent is to share your Access database with remote users, you might consider an Remote Desktop Services (RDS) setup. This allows users to log into your local system via their RDS connection, and use the Access application just as they would from their local desktop. This takes an investment of money (and time, if you must setup and manage it yourself), but it's a quick way to have remote users. There's also at least one online hosting service: There's a monthly per-user fee for this service.

In the end, the advice I give is always this - if you want your application to be accessible from the web, then bite the bullet and learn a web-based language like PHP, ASP.NET, Java, etc etc. You'll never get the same results trying to force a desktop product to behave like a browser, and you'll end up learning a bunch of stuff in the process!

Now Microsoft is giving up on sharepoint pushing iot to godaddy.
I'm not sure what you mean by that. GoDaddy is a web-hosting company, and while they've partnered to provide a more easily accessible 365 site, they are certainly not the only game in town regarding Sharepoint. Most major hosting companies offer some for of SP hosting, and you can always create your own SP environment and host it yourself.
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"These are run entirely in a browser (you can use Firefox, Chrome, etc to run them), and are hosted on a Sharepoint site."

Just to clarify ... Sharepoint is only the administrative portion of Access 2013 Web Apps, as opposed to Access 2010 Web Databases - wherein Sharepoint (Lists) was the actual backend. In A2013 Web Apps, you automatically get a full blown SQL Server (Azure as noted) backed, hosted by Microsoft (or your own company) - including all the performance and security you would expect from an SQL backend.  

Further, from the Desktop side of A2013 - you can via VBA code - link to the tables in the Azure backend (I have done this) - such that you can have a browser based UI for end users (with limitations mentioned by Scott) and a more robust 'admin' front end on the desktop side to manage tables, etc.

"connection via your internet connection, which is inherently flaky."
Humm.  Well, my internet connection is not inherently flaky. And many, many major organizations rely heavily on internet connects for normal business.  So I don't think I would let this be a deterrent.

Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Well, my internet connection is not inherently flaky.
Everyone's internet connections are inherently flaky, in that they drop/reconnect, are rerouted, etc as needed. I'm not referring to your companies LAN/WAN, which is a private network, but rather a "in the wild" connection. If you truly think your internet connect is rock solid, I'd suggest you download wireshark and monitor your actual internet connection (not the one at your computer, but one on the wild side of the modem). You'll be surprised at the amount of drop/reconnects you run into. Your browser handles those scenarios quite quite well, and will reconstruct the items needed to work with your browser. Access doesn't do that nearly as well.
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
" I'm not referring to your companies LAN/WAN, which is a private network,"
Nor am I ... at all.
Industry is heavily dependent on 'internet connections' - to all kinds of databases, etc. So ... if it was as bad as you say, then things would be imploding on a regular basis nationwide.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
I think you've misunderstood what I mean. I did not say that ANY application would have troubles with an internet-based data store, but rather that Access would have troubles connecting with that sort of platform - hence the reason I wrote "Access doesn't do that nearly as well.", which you apparently did no see in my earlier post.

Most of those "industry" application you refer to don't use bound UI objects, nor do they perform data manipulation at the UI/UX level. Instead, those applications would that rely on internet-enabled connections would have a data layer that would take steps to mitigate those sorts of issues. The UI would pass off the data needs to that data layer, and the data layer would manage all of that.

Access doesn't have that sort of middle tier in a bound form. If you were to move to unbound, of course, and create your own data layer, you'd be better off, but you're still stuck with DAO, or the older ADO technology (not ADO.NET, in other words).  And if you're going to the trouble of running unbound, then you should probably consider moving to a different platform, like a web language, or a desktop app written in .NET or Java.
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Well ... I was referring specifically to an Access 2013 Web App UI (in the browser) connected to an Azure back end in the cloud - via an internet connection.  

Now ... on the desktop side ... where I said you can via VBA code link (aka the bound paradigm) to the same Azure back end tables - sure ... that would be more iffy - no argument there. But in this paradigm, using Jeff Conrad's Restaurant Management App - and specifically the desktop portion which is a 'back office admin tool' as an example, this would not be a full time connection - only when necessary to update lookup tables, run reports etc.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Exactly - a web-based app, like a 2013 Web App, would be easily able to manage this sort of connection, as I said earlier.

A desktop Access app with bound Forms/Reports, linked to Azure, would not.
Eric ShermanAccountant/DeveloperCommented:
Here's my $.02 on the subject and I'm not at all a web developer and have a great appreciation for developers who have invested the time energy and effort to master the languages needed to develop web apps.  Developing web apps to replicate what a typical desktop application like Access does is very complex.   Most users, department heads and decision makers generally feel it's just a matter of copying a well designed Access desktop application that have been running successfully for them over the years, tweak it a bit and turn it into a web application that can run in a browser ... not so.  To duplicate that type of functionality with forms, reports, etc. would take a team of web developers literally months or even years of development and even then the functionality would not be the same or exact.  

Access simply works best in a desktop Windows environment ... hands down.  When I conference with clients I try to get them to determine if the need to run their business logic in a web browser is more important than having the functionality of a desktop application and the ease of rapid development/deployment.  If it has to run in a web browser then you will need some deep pockets in most cases ... web development is not cheap.  

I generally use M/S SQL Server or MySQL with Access as the Front-End.  It is a solid setup and it works with the horsepower of a Windows desktop/laptop/tablet.  I redesigned the front-end of a 10 year old Access CRM application for testing at a clients request.  We used MySQL as the back end with Access as the Front-End and distributed to Windows Laptops for field technicians to test with entering work orders and other information including Timeclock transactions.  I built the front end using a method where it would not link to all the tables and carry all that overhead.  Instead, the queries would connect to the Back-End MySQL tables when needed to query or post and update table data then disconnect.  We tested with the laptops using a 4G cellular connection to the internet.  It worked flawlessly and we never had a problem with it.  They got all the functionality they needed and were accustomed to, plus rapid development and never had to mess with a web application and developing.    

Sometimes you just have to evaluate what you really need and how you want to go about getting it.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
Most users, department heads and decision makers generally feel it's just a matter of copying a well designed Access desktop application that have been running successfully for them over the years, tweak it a bit and turn it into a web application that can run in a browser
I can't tell you how many phone calls and emails I've gotten over the years that start out with something like "I've got this Access database and want to convert it to a web app. Should be simple". They are two distinctly different environments, each with good and bad, and each designed to work very well in their environment.
Eric ShermanAccountant/DeveloperCommented:
Same here Scott.  I had a client that wanted to take a complex Access Front-End app that runs queries and reporting against SQL Server tables reporting information for their customer base which could includes history going back 5 years and make it an Android app.  A cell phone processer would not deliver that information with the horsepower of a Windows laptop.  

Helen FeddemaCommented:
It can be done in Access 2013, but it is far from easy.  My recent ebook, the Office 2013 Startup Guide, has detailed information on how to set up an Access 2013 Web app with a SQL Server back end (using Office 365).  But I must say that what worked (with a lot of trial and error experimentation) in 2013 quite possibly might not work in 2015.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SharePoint

From novice to tech pro — start learning today.