Multiuser Environment 1

[adalli]

Hi,

I created a VB6 application interacting with a MSACCESS 2000 MDB. I am planning to install the application on Win2003 Server and the users access the application through the Server (Via a normal shortcut).

The application uses the registry to extract the database path, and it even uses a number of DLLs I have created.

Would anyone know if such a setup would create any problems?

Thanks

 

[dilettante]

If this is just a typical "flat" VB application (really 1 tiered, though people like to think of these as 2-tiered for some reason) you won't get too far.

The program runs on the client desktop. That means it will need the DLLs, DLL registration, and misc. registry entries to be local as well.

To minimize this requires breaking the application into a separate front-end client and a service. If you keep access to your database and custom ActiveX DLLs in the service part of the application you can reduce the amount of client installation required. This service can be anything from a DCOM server to an always-running application to a formal NT service.

You can also accomplish this by leveraging an existing standard system service like the Telnet server, MSMQ, or IIS for that matter. Then your client just connects using Telnet sessions, queues, or HTTP requests that in turn trigger instances of your server-side code.

All of that is a lot more work of course than building simple flat VB applications. For these you will need to do a formal installation though instead of just placing a shortcut on the desktop. You only get away with that when you can assume the right VB runtime is already present, you use only intrinsic or very common controls, and you don't rely on other machine resources like registry settings for application parameters.

Proceed anyway, that's a very common way to build applications. But you will need to install your application on each client.

 

[dilettante]

Another thing one can do to reduce the cost of installing a VB application on each client is to include (compile in) all of the classes you use. That is, take the logic from your VB DLLS and put it into internal class modules.

Then if you use INI files or the like for application settings instead of registry entries you'll have reduced external dependencies a bit. This may possibly be enough to make file share deployment do what you want it to.

It still assumes that you have the appropriate VB runtime installed on client systems. It also assumes you use only VB's intrinsic controls and a few unlicensed ActiveX controls that you can assume to be installed with Windows. For example the Winsock control would probably not work.