I have several .asp applications in which I connect to a MS Access database using VBScript code in my .asp page. I have read somewhere that it is better to wrap database calls in a .dll. Why is this better, and how do I do it (or where can I find more information).?

Where did you read this? I don't know if it's better. Better for what? Performance or Security? Instead, I personally believe it's better to use Stored Procedures directly from your ASP, but then, I don't know if there are Stored Procedures in Access. If you are determined to write DLLs (and with Access, you may have to), you'd use Visual Studio to create ActiveX COM objects (which compile into DLLs). Then you register the COM objects with the OS (regsvr32.exe from the command line).

A benefit of using COM objects is that it compartmentalizes your code, and can be reused by the OS easily instead of rerunning the same code in ASP. Secondly, a reason which holds more water for wrapping DB calls in COM objects is security. If someone hacks your web server, and all your code is in ASP pages, they can find out the username, password, and address of your db server (which may also be your web server) and can use that info to get into your database and grab personal info. When you compile the DB connectivity, this information is not easily accessible.

My qualm with COM objects is that every server needs the COM object registered, and re-registered when you re-compile the code. I use a content management system to deploy my code to many production web servers. It is tedious to have to touch every production web server just to register an object.

Thanks for the enlightenment...it is very helpful. I read it on a company intranet, and they require it for any web database application. Presumably, this is for security and to ensure privacy policies regarding stored personal info as you suggest.

Hmmm. I suppose it depends on the information your DB contains, but I'm generally not as concerned about security on an Intranet for non-sensitive information.