Web Enabled Access
So you want a web enabled Access App? Here's your options:
(please note the distinction between "Web App (2013)" and "Web Database (2010)". This is official terminology and will be used throughout)
There's more, but that'll be plenty to give an overview of what we can do (only the main points will be covered here, the rest become more or less self-explanatory). This is essentially a matter of determining what it is you need from your application, and choosing a model that best fits those needs. As you can see, there's quite a number of different ways we can go about this, each with their pros and cons. Here's a quick overview of the main ones listed above, taking a closer look at the pros and cons, as well as some example scenarios.
Access Web App (2013): GUI through Web Browser, no client installation required, anyone with a browser can access it (provided they have user login rights). Data stored in a semi-locked down Azure BE (cloud hosted, taken care of for you). Ability to make a public (don't require login), ability to embed in SharePoint/Office 365 sites.
Access Web Database (2010): GUI through Web Browser, no client installation required, anyone with a browser can access it (provided they have user login rights). Data stored in SharePoint Lists. This entire model isn't officially deprecated (that I'm aware of), but is certainly a dead end.
Access Desktop Application with Cloud Based BE: By using a cloud base BE and a Desktop application, we can have the data itself shared globally while retaining the robustness of Desktop applications (including VBA projects). Generally speaking, we can use whatever BE we want in this scenario: Azure, SQL Server, MySQL, Postgres, etc, so long as it's hosted on the cloud somewhere (there's many hosting companies available). A measure of concurrent users is regulated by the BE of choice, but generally speaking any of those mentioned should be able to handle a much larger amount of users than Jet/ACE (eg, much more than a local Access BE)
Access Desktop Application on Terminal Server/RDP: If you have an existing desktop application and want make it available to a few people without location restrictions, this is often the easiest way. Essentially, you just give the required people remote access to a computer that has the application installed. This can be done by opening the existing computer to accept RDP connections, or by moving the application to a dedicated computer (or by putting the application on a hosted Virtual Machine).
Hybrid Desktop/Web App Database: Here's an interesting solution. Keep your existing desktop/LAN database in place, add a Web App separately, and as a feature extension of the original LAN setup, you can connect to this to the Web App's underlying Azure database to interact with that data as well. This could mean a push/pull setup (where the local DB takes information entered via the web app, and possibly pushes a bit of core data to it as well), or - less likely – could have the local database integrate the Web App's Azure database so the core data from the desktop application is actually hosted on the could as part of the Web App.
This model can actually encompass the rest of the stuff in the initial list in the article. The same idea can be used with 2010 Web Databases, where the data is stored in SharePoint Lists. Access can connect to these lists, or really to any other data source. In fact, it's a fairly safe bet that many organizations with a central database system implement some sort of external data store.
An excellent use case for this type of scenario would be for a travelling salesman. His company's core database would be set up on a LAN back at the office, but they've also provided a nice little web app so he can use his phone or tablet to jot down a few notes and check-in/out times while he's out there making calls. Maybe even track expenses and miles. Meanwhile, as part of the nightly automation routine back in the office, the data he entered throughout the day gets imported into the main database and is removed from the Web App.
A not so excellent use case for this would be an office that has many people working remotely, at the level where these people require a "real" application to get work done, rather than a relatively simple web tool for smaller tasks. They'd need realtime information from the main database, extensive sets of features from the application, etc. Such cases would present two major problems with this approach: 1) robust applications with Access Web Apps are difficult, and 2) the data syncing between the office and the remote apps would be a nightmare. In this case, a cloud based BE or remote logic to the company network via RDP or VPN would be a much better solution.
When it comes down to it, there's a number of ways to make your database web enabled – some more "enabled" than others, and each tends to have their strengths and weaknesses. By understanding what's available, what the implications are in terms of functionality, cost, ease of implementation and the how well of a path forward it leaves, we can then make a good decision on where to invest our time and resources to get the best return for what's required.
With any luck at all, this article has helped break down what to expect and provide some sort of general direction.
|This page has been accessed 10,884 times. This page was last modified 12:50, 19 November 2014 by Jack Leach. Contributions by rabroersma Disclaimers|