IN the rush to build Web applications, Access developers may have felt left behind. While it’s certainly possible to access your data in a Jet or SQLServer database from a Web application, and while there are certainly ways to move ADO data back and forth over the Internet, Access isn’t a Web development tool. The closest that you get to Web development with Access is Data Access Pages—at best, a tool for distributing reports across the Internet.
The only consolation is that the real Web development tools are awful compared to the wonderful environment that Access provides (and I say this as a consultant with about 50 percent of my business in building Web applications). The Web’s combination of server-side code and stateless applications makes for awkward application development. The lack of control over what the client is doing requires a great deal of defensive programming just to make sure that the program won’t die because a user on page 4 hits the Back button three times and returns to page 1. If you wanted to create a functional client-side environment, you were forced to use a cobbled together stew of scripting languages, HTML, cascading stylesheets, and the HTML Document Object Model. The reality of multiple browsers with multiple versions, all with different support for these technologies, is just icing on the cake. Finally, integrating the interaction between the client and serverside environments requires ad hoc Rube Goldberg solutions. It’s hard not to feel sorry for Web developers, quite frankly.
The latest Web-based technology, however, changes all the rules. Web Services provide a uniform way of accessing applications residing on a server from any client built with any application development tool. This means that you can build a fully functional client and reach over the Internet to any application on any server and communicate in a meaningful way. There are missing components in this framework (transactions and workflows), but these are being addressed.
What has this got to do with Access? Simply put, your Access application can work across the Internet to interact with any server application. My August 2002 article, “Web Services for the Access Developer,” is an example of how to access a Web Service from Access. In that case, the Web Service was the Google search engine. Thanks to Web Services, a client built with any front-end tool—Access, for instance—can work with any serverapplication across the Internet. That, in my mind, is what makes any tool a Web application development tool.
Of course, there are objections. People say that Access isn’t a Web development tool so an application that uses Access can’t be a Web application. That’s true, but only because these people have defined a Web application as one that uses a Web browser as a front end. Not only is that definition narrow-minded, it’s also dumb. I can’t imagine any reason why someone would willingly choose to work with a Web browser if they had any other choice.
There are only two real objections to using Access as the front end for a Web application. The first one is that Access is optimized for creating database applications and isn’t a great Web Service front end. However, there really aren’t any tools optimized for accessing Web Services (yet). And who knows what “optimized for Web Services” really means? ADO.NET lets me convert my datasets to XML and move them across the Internet. To optimize Access for Web Services, all I really want is to be able to set the control source for an Access form to be the name of a Web Service. The Web Service will have to return an ADO.NET dataset based on a SQL statement and, in return, accept SQL statements that will make my updates for me. The Access form can take care of moving the ADO.NET data to the form and generating the SQL statements based on my user’s inputs.
The second objection to Access as a Web development tool is more telling: Access isn’t an easy install and runs only on Windows. Using Access as a front end means that you’d have to send your users a CD with an installation package. They’ll also have to be using Windows. That hardly sounds like the end of the world. And, of course, if Microsoft were to rewrite Access as a .NET application so that it would run on any computer with the .NET Framework installed… well, that would change everything, wouldn’t it?
