Image of Navigational Panel mapped to Contents / Home / Search Access 2.0 Databases
Tech Support Question
Image of Line Break

Q. Hi. I just read an answer to a question about difficulty with VB3.0 and databases. You stated at the end of the answer that you could download COMLAYER.EXE and that you would be able to access Access 2.0 databases. It was my understanding, when I read the docs with the file, that it would only work if the destination (user) computer had Access 2.0 installed.

My question: Is this true? I would like to be able to access Access 2.0 databases from VB3.0, but there is no guarantee that the end users would have Access 2.0 installed.

I realize that I could use VB4.0, but in preliminary beta testing, I was unable to perform a successful install of a VB4.0 (16 Bit) app into a Win3.1 environment. Hence, I am using VB3.0.

Thanks for any information,
From: Tony
Email: paulic@inforamp.net

A. In answer to your question about the COMLayer this will certainly work if your target system has Access installed, but basically it just changes the DLLs you need to ship with your VB3 app. Without the comlayer you needed to ship the JET 1.1 library which was called MSAJT110.DLL.

Once you have installed the compatibility layer you instead need to ship MSAJT200.DLL, and MSAJT112.DLL. this gives them the JET 2.0 engine and the VB communication layer to same. So, no they do not need to have Access installed.

Betas of VB4.0 16 were a bit dodgy for a start, however, the problem you are probably having with installing it is that JET under VB4 is an OLE server so you need to register each DAO/JET DLL that you install for your app. The safe bet is every DLL that you install you should attempt to auto register as an OLE server. You should then find that it works.

Hope that helps you. Let me know if you want more details or whatever, this was just a quick reply between doing some actual work. (grin)

Q. How do I auto register the VB4.0 JET? During setup I was shown a box that indicated that I had the DAO dependencies. I left the box checked thinking it was enough. Is there something else that I need to do?

I found that when installing onto a WIN3.1 computer (compiled with VB4.0-16) I got a variety of error messages. The most common was "Cannot load Windows' versioning library". After some investigation, I noticed that it had replaced the VER.DLL file with a newer version. In addition, after this replacement was done, I couldn't even run the Windows' Setup program from within 3.1. Kept getting "You need a newer version of Windows" error. I replaced the VER.DLL with the older one (shipped with WIN3.1), and the program worked.

So then, I recreated my setup and included the old VER.DLL into my distribution disks. I got as far as a "Cannot run program error" error and all stopped. I then threw the VB4.0 disks and everything else VB4.0 into the "Pile" and went back to VB3.0. I sure would like to use VB4.0 though, better DB control, more data-bound controls, classes, etc. However, since a lot of my apps run on WIN3.1 computers, I can't use it unless I can get a reliable install.

Thanks for your help. If you have anymore suggestions I'd love to hear them.
From: Tony
Email: paulic@inforamp.net

A. The distribution of VB4 apps is certainly more problematic than the distribution of VB3 apps. Unfortunately, the OLE aspects introduce complications, as does the interaction with the registry. Certainly even reading settings in the Win95 registry takes a lot more getting used to than looking at INI files...

The first thing to understand is that VB4 uses the JET engine as an OLE server. This means that it has access to the functionality of the JET engine using more or less the same functionality that it uses to interact with any OLE servers you might build using VB4. At least, the principles are the same - but the performance has been beefed up. What this means is that no only do you now have to distribute the JET DLLs as you did with VB3, but you now have to register them as OLE servers. This means loading them into memory so that they will write their registration information into the registry. Using the VB4 setup wizard is supposed to do this automatically. However, you might want to try using the REGSVR[32].EXE application available in your VB\CLISVR directory, to manually register OLE servers. Another file called REGOCX[32].EXE can also be used to manually register OCX components.

If you are using a third party installation program it should have a function to allow you to automatically register OLE components of all sorts. Personally I could not recommend WISE from Great Lakes Business Solutions more highly, it makes this whole process very simple. WISE understands VB4 applications and can automatically determine the required components and arrange to register all OLE components.

You are indeed right about the status of VER.DLL, when the 16bit setup wizard decided that it needed VER.DLL it conveniently grabs the nearest available copy, which is of course the Win95 version because you are compiling on a Win95 machine. I would recommend that you always compile 16bit applications and installation disks under Windows 3.11. It tends to avoid these sorts of peculiarities. Also, I have observed some problems compiling 16bit VB apps under Win95 as it resolves API references ever so slightly differently.

Don't give up on VB4 just yet, it has some problems but they can be resolved. I hope this helps to point you in the right direction. Good luck.

Image of Arrow to Next Article

[TECH SUPPORT TOC]
Image of Line Break
[HOME] [TABLE OF CONTENTS] [SEARCH]