Peter Vogel Silver Collection
MANY of the Access developers I work with have companies that want to move their applications either to Visual Basic, Visual Basic.NET, or the Web. I’ve discussed the issues around going to Visual Basic in earlier editorials, and they haven’t changed for VB.NET: You’ll probably have to rewrite your application from scratch, using the Access application as the specification. Unless you change your application’s architecture it won’t run particularly faster, since most database applications are constrained by the speed of retrieving data from the database. You’ll need to change the way that your code is managed since the Visual Basic form fires different events than the Access form. Unless you need to do something in your application that can’t be done in Access and can be done in Visual Basic (or Visual Basic .NET), I don’t see the benefits.
Click on this button to see how it can be done now, how times have changed.
So what about the Web? As Danny Lesandrini points out in his review of Access Reporter .NET for IIS, the only reason that you move to the Web is to reach a broad range of users. And, even then, the Web is your choice only when it would be difficult or expensive to install a client application on the user’s computer. The beauty of the Web is that your users already have their client installed—a Web browser. The fact is that HTML + serverside code + client-side code is a tremendously awkward development toolset. But, when you have no choice, it doesn't matter. This isn’t sour grapes: Half of my business as a consultant is involved in creating Web applications—I like building Web applications and I’m good at it.
The reason I bring this up is that I hear a lot of reasons for moving to the Web that simply aren’t true. My last client wanted to move an Access application to the Web because, “Our applications will run faster.” Nothing could be further from the truth: Web applications run slower than client/server applications.
The basic processing cycle for a Web application is simple:
1. The user requests a page from the Web server.
2. Processing happens on the server.
3. A page is sent to the user.
4. Processing happens on the client.
5. Data is returned to the server with a request for a new page.
6. Processing happens on the server.
7. A page is sent to the user.
8. Repeat until the user gives up.
How is this different from any other client/server application? There are two differences that matter, at least as far as speed goes: • The Internet is a very slow link. • Instead of just moving data to the client, in Web applications the HTML for the user interface, any client-side code, and the data are moved from the server to the client.
In an intranet environment, you can speed up the network. However, the movement of the HTML page is inherently less efficient than just moving the necessary data to the client. So, Web applications will run slower than the equivalent client/server application. And that’s what I told my client. Unfortunately, my client told me that they had an application that was running considerably faster since they moved it to the Web. This intrigued me enough to investigate.
My client had started with an Access application that requested literally hundreds of records from the company database. Once the records arrived at the client, Access filtered the result and displayed only a very few of the records to the user. In its original client/server mode, the Access application was moving those hundreds of records from the server to the client.
So what happened when my client moved the application to their intranet and rewrote it to run as a Web application? To begin with, my client spent a lot of money rewriting the application. And, by that, I mean a lot of money. They also ended up with an application with less functionality and a more awkward user interface than the original application.
But with the rewrite, the code in the Access application effectively moved into ASP code running on the Web server. The Web server was in the data center with the database server, so moving those hundreds of records from the database server to the Web server became much easier to do. The code on the server filtered the records down to the few that the user wanted, embedded those records in a Web page, and sent the page to the user. With filtering occurring on the server, the number of records being moved to the user actually decreased substantially, giving my client the speed increase they saw. Of course, with each user retrieving hundreds of records to the Web server, the application had substantial scalability problems. We’ll pass over that problem in silence.