Need a Microsoft Access Developer or Programmer?

Contact:
Dean Serrentino

MA, NH, RI, CT, ME

(978) 694-1043

  • Developer
  • Programmer
  • Consultant
  • Trainer
  • Mentor

How can I use my Access database on the Internet?

If you are looking for a developer to web-enable your Access application, please contact me (978) 694-1043.

It often happens that well-written Access applications are so popular, that their fans want to further expand their usefulness by web-enabling them. In my experience, this is a topic of great misunderstanding. Many people are unclear of what Access can and can't do when it comes to its use on the Internet. I have, therefore, authored this page in order to dispel some of the confusion.

The bad news is, you CAN NOT use your Access application across the Internet, at least not directly. The only real exception to this is the use of a VPN (virtual private network). A VPN may be a viable option if you have a small, fixed number of users and your application is not data intensive. If you don't fall into this category, don't despair; all is not lost.

The term 'Access database' is often used incorrectly. Access is not a database. Access is an application development environment, which can make use of many types of databases. Access's native database is JET. A JET database CAN be shared across the Internet by using any one of several techniques. Access applications, on the other hand, run only in Windows. Using an application written with Access requires each user to have a copy of Access installed on their workstation. Even if it were possible to do, this would not be a practical solution for Internet use, because you couldn't make any assumptions about what version of Access each user had, or if they even had Access at all.

What about Data Access Pages? Data Access Pages were introduced in Access 2000, as a way of giving Access some browser functionality. They never caught on, and were subsequently removed from the product in version 2007. The use of Data Access Pages requires that each client computer have a copy of Microsoft Office Web Components installed. Again, this is something that you, as a developer, can not control, unless your users are all within a single organization. This makes Data Access Pages unsuitable for Internet applications. Furthermore, there are much better technologies for doing this type of work.

Using HTTP requests, data from a local JET database can be shared across the Internet with many other types of databases, such as MySQL, SQL Server, or even another JET database. This is a 100% code solution. I recommend this method only for pushing or pulling select pieces of information. Although it could be used to synchronize the data from an entire application, it would be a very laborious endeavor. This technique not only requires good VBA coding skills, but also some expertise in a server-side scripting technology such as ASP.NET or PHP.

The bottom line...

You can re-use your Access data on the web without much effort. Your user interface (forms and reports) on the other hand, can not be used without a substantial amount of re-work, or outright replacement.

Options

There are essentially two solutions, with variations of each.

1) Access back-end with a browser-based front-end

Your Access database lives on the web server. Data is accessed using web pages generated by server-side scripts such as ASP.NET, PHP or ColdFusion. In most cases, this is the best choice.

Pros

  • Changes to your application do not require distribution to client machines
  • Changes to your application are instantaneous
  • A convenient opportunity for up-sizing the database to SQL Server for improved performance and scalability

Cons

  • Your entire front-end application must be rewritten

2) Separate back-end and front-end Access database files

Your Access data lives on the web server, while your Access application lives on your client workstations. The two files exchange data via a web service or simple HTTP requests. The web service acts as a proxy, sending data back and forth.

Pros

  • Your user interface remains unchanged
  • Almost all of your existing Access objects are reusable

Cons

  • Forms and reports can no longer be bound to data
  • Code must be written to exchange data with forms and reports
  • All users must have Access (or the Access run-time version) installed
  • Changes to your application require distribution to client machines