VB Installation Error (VB6/Access 97)

Topic

New Reply

I just built an application in VB using a Access 97 back end. I created an installation package using the package and deployment wizard. I had no problem installing it on my test computer (just a generic computer that does not have VB installed). There was a point where the installation program stated that I had to install a component then reboot my computer. I clicked okay and rebooted my computer and ran the installation program again. It worked fine.

On two other computers, it asked the same question, we did the same thing…but after the computer rebooted and I started the install again, it asked the same question again. Each subsequent time it would do this and never let us complete the installation.

Has anyone else had this problem and figured out the solution?

Something else probably worth mentioning:

On the machines that I’ve been able to successfully install this thing on, during the installation it tells me that the file I’m trying to copy is older than the one on the destination machine (or something like that). The file names are as follows:

msjet40.dll
dao360.dll
scrun.dll

In VB I am running SP4 (didn’t want to load SP5 because I’ve heard some questionable things about it, but I shouldn’t have to I don’t think). Is there something else I might have missed on my initial installation of VB? I’ve had it installed and have been using it for several months.

Reply | Quote

Replies

You may have a couple of things going on there, Mike. For one thing, the Jet and DAO library files you listed (are those the ones on the machine or the ones you’re installing, BTW) are for Access 2000, not Access 97. VB 6 comes with the Jet engine for 2000 so why are you using an Access 97 back end? Also, on the machines where you had problems, are they running the same OS as the one that succeeded, and do they have any version of Access installed?

I personally haven’t had any trouble with SP5, so I wouldn’t worry about applying it if you need it, unless you’re running an OS it conflicts with.

Reply | Quote

Hi Charlotte,

Good questions. Ummmm, regarding the files I listed (if I understand correctly), are the files the installation program saying that I am trying to install. Specifically, that those particular files exist on the machine I’m installing to and the files I’m attempting to install are older than the one on the target machine. It is the generic message that recommends that you keep the file that is on the maching due to it being newer. (Did I answer the question?)

On my development machine I have Access 97 co-existing with Access 2K. From what you said I’m guessing that this may be the root of the problem.

I used Access 97 as a back end because that is what is installed on my company’s machines. But, are you saying that I could use Access 2000 and VB will read the data, even though it is Access 97 on the machine the VB program is being installed on?

To answer your last question, all of our machines are running Windows 98, however of the ones I’ve tested this on, also have Access 97 installed.

Mike

Reply | Quote

There’s another issue. If you use Access 97, you should be installing the libraries that support it. You do not want to install older libraries over newer, and in fact, I normally install my runtime libraries in a different folder so that I don’t run into this problem. However, if you’re using the Packaging and Deployment Wizard, which is only marginally less pitiful than its predecessor, you may not be able to control that.

Reply | Quote

Yes, each time I do the installation I choose NOT to overwrite the newer files.

What do you think of Install Shield (that is the only proprietary installation utility I can think of).

Considering what we just discussed, I ran a test to install the program on a machine that has ONLY Access 97. It had the same – newer file overwrite- warning, but it installed and ran just fine.

Reply | Quote

I like InstallShield Express because it works much like the Packaging and Deployment Wizard but gives you more control and better results. However, if you want to install a 97 version on an Office 2000 machine, you’re better off with InstallShield Pro or the Wise installer, both of which are programmable and can use SageKey scripts.

Reply | Quote

I haven’t heard of SageKey scripts, but they sound very versitile. Is Wise installer part of InstallShield or a different product?

Reply | Quote

They’re two separate products. SageKey produces scripts for both.

Reply | Quote

Hey, after you post your reply, look at the date/time stamp of the message in the Entire Thread frame. Is it giving you an accurate time? Mine is showing my last post was made at 2:21 this afternoon.

Reply | Quote

I don’t know what you’re seeing as regards time. My time appears to be off an hour, so it looks like someone has been tweaking things.

Reply | Quote

Charlotte,

Did you mean that I can develop an application in VB using Access 2K on the back end, and install it onto a machine that doesn’t have any version of Access installed? This was in reference to your statement (or question) “VB 6 comes with the Jet engine for 2000 so why are you using an Access 97 back end? ”

Mike

Reply | Quote

As a datapoint, I distribute a solution created in VBA and hosted in a Word template. When a new document is created from this template, the procedure checks for the existence of my small Access 2000 database and, if it isn’t found, downloads it from a server. (This database contains queries; I think this is marginally faster than having them in the code.) The procedure then checks a local .ini file and updates the links in my Access 2000 database to tap into an Access 95-format database that is maintained in our timekeeping application (some users have local data storage, others are in network user folders). After than, I use VBA and Word to create substantially better reports than the underlying application ever hoped to output. (In my humble opinion.)

The users require Word 2000 and ADO 2.5, which is installed with the Office 2000 SR-1 update (I switched the code that updates the table link from DAO to ADOX, and that’s a pretty recent innovation, apparently). If they don’t have it, they get an error “cannot open macro storage” or something like that, and our IT guys either install the SR-1 patch or install the MDAC 2.6 update from Microsoft. It’s a one-time fix. Virtually none of these people have Access; ADO, the Jet engine DLL, and VBA do all the work. Make sense?

Reply | Quote

Yes, Thanks. It sounds like I put in a lot of effort to create the back end in Access 97 because it was on their computer when I didn’t have to.

Reply | Quote

I have a little more information on this. It appeared at first that I only had the problem when installing this on a machine that had Access 2K installed. This doesn’t seem to be the case since I just tried installing it on three machines of the end-users, which all of them failed, and all of them are supposed to have the same image as the test computers I successfully installed this app on. So, I did some investigating and I think I figured out, well, at least why the problem is occurring.

The installation was generated using the package/deploy wizard and put on the network. I’ve been installing this using the installation directory on the network to create a local installation. At the point where it asked to re-boot after registering a component a second time (which is where this endless loop of “you need to register this component and reboot” occurs) I exited out of the install and tried launching the program EXE (from the install directory). It told me I was missing component titext6.ocx. I searched the HDD and found this ocx in the Windowstemp directory. I searched the registry and found it registered using the path of the installation program on the network. The reason I think this is the point of the problem is because it is my understanding that the actual registration occurs during the re-boot process. Well, the computer isn’t connected to the network at the time of the registration so the registration fails. Thus, I get this endless loop of having to re-register this thing.

In my probably not so infinite wisdom I deleted the local ocx and blew away the registry setting referencing the file on the network. Running install again just recreated the reference to the ocx on the network install directory. Deleting this again, I tried copying the ocx to the WindowsSystem directory and registering it myself using: C:WindowsSystemRegsvr32.exe/s C:WindowsSystemtitext6.ocx

It didn’t seem to work unless I put the /s switch in, which doesn’t return a prompt. In looking at the registry, I did a refresh, and it pointed (again!) to the ocx on the network.

The only thing I can think of is that you are supposed to unregister an ocx before registering it again, and simply deleting it from the registry probably isn’t enough. Since I have to do this in DOS, and to make it more readable to the end user I used a space in the directory name “Roadmap Install”, I don’t know how to reference the space in DOS (I know it uses a tilde somehow, but I couldn’t even do a CD S: to change directories to the network drive so I could do a DIR and see how it is referenced there).

Am I on the right track, and if so, I hope someone is able to tell me where to go from here because I just hit a major dead end.

Reply | Quote

take a look at MSKB articles and HOWTO: Deploy an ActiveX Control with License Information (Q188582) and see if they give you any ideas.

I suspect you’re right about the source of the problem being the network drive. I’m not sure what you mean about having to do this in DOS, but if you have a space in the name you have to truncate it with a tilde and a number. In your case, it would be something like Roadma~1.

Reply | Quote

I read those two articles. It didn’t apply to my particular situation, but they were interesting – especially the Deploy and ActiveX Control with License Information.

I would like to try unregistering that component on the network. I’ve noticed that sometimes the tilde has a different number after it, and does it always go after the 6th character in a word that has a space in it?

My path is as follows:

S:RoadMap Installtitext6.ocx

Of course, the Roadmap Install directory is now called RoadMapInstall, but whatever is storing the registration information thinks it is there.

Reply | Quote

The tilde and number come either at the space or after the 6th character in a longer word. It’s the short filename format that DOS supports. If you have several folders with the same first 6 characters (i.e., Microsoft Whatever) you’ll have a series of short names with sequential numbers so the OS can tell the difference between all those Micros~# items.

Reply | Quote

I think I understand. So I would write

S:RoadMap Installtitext6.ocx

as

S:RoadMa~1titext6.ocx

Reply | Quote

Charlotte,

I wanted to close this out by posting what I did to resolve this problem in case anyone else runs into it.

I’ve been able to determine that the Package/Deployment Wizard copies dependency files (DLL’s, OCX’s) to the Windows Temp directory, creating a sub folder called MSFTQWS.PDW. On my machine it is WindowsTempMSFTQWS.PDW.

It seems clear to me that the WindowsTempMSFTQWS.PDW directory is a staging directory in which the files are kept until registered on reboot. Why it doesn’t recognize this after the reboot is unclear. But the solution was to copy all the files in this directory over to the Windows System directory and then register each using Regsvr32.exe.

I wrote a VB program that looped through the MSFTQWS.PDW directory then registered each one by one using the Windows API. The only problem was that usually at least one file was already registered in the system directory and it wanted to update it with a newer version. Since it was in use by Windows it wouldn’t let me copy the new file over it. I rebooted into DOS and copied the file over into the Windows System directory. After running the setup program again, it launched the installation program, which concluded successfully.

Reply | Quote

Thanks for the update, Mike. I changed your subject line to show you had found an answer.

Reply | Quote

If you open your Setup.lst file, what does this section look like?

[Setup1 Files]
File1=@MSCOMCT2.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),2/22/99 12:00:00 AM,640272,6.0.84.18

I’m not sure exactly where in the project/wizard you make very clear that the OCX needs to be on the client PC, but I’m sure it’s in there somewhere.

Reply | Quote

Hi Jefferson,

I have two setup.lst files on my computer, both in a Data Environment Utility sub directory off a personal directory I created. Both have identical entries, as follows:

[Setup1 Files]
File1=@MSCOMCTL.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),5/22/00 12:00:00 AM,1066176,6.0.88.62
File2=@TABCTL32.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),5/22/00 12:00:00 AM,209608,6.0.88.4
File3=@BAG_DataEnv.dll,$(AppPath),$(DLLSelfRegister),,4/20/01 9:31:48 AM,114688,1.0.0.6

Oh, and I verified that the package/deploy wizard had $(WinSysPath) set up on all those files, which they were already. I also verified on the user’s machine that the WinSysPath was in the correct directory.

Mike

Reply | Quote

I wanted to update everyone on what I’ve tried (and failed).

I did a search of the user’s registry and found several different keys with the ocx registered to the network path instead of the local file reference. I deleted all these keys, then deleted the titext6.ocx from the installation directory so there is no way in hell that it could try to register it on the network. I also moved the installation folder from the network to the user’s machine.

That part worked, after running and failing on another install, I did a search of the registry and all the path references to the ocx were now to the local directory. I’ve been trying to launch the exe directly from the installation package just to see which dll or ocx error it gives, and it returned an error saying that the titext6.ocx (same file) is not properly registered. I tried to unregister then register it again myself, but I think the command I’m using isn’t working:

C:WindowsSystemRegsvr32.exe/u c:WindowsSystemtitext6.ocx
C:WindowsSystemRegsvr32.exe/s c:WindowsSystemtitext6.ocx

Trying the above regsvr32 commands on my machine works. Now check this out: I left the titext6.ocx unregistered, deleted EVERY reference to it in the registry, then executed the exe file directly from the install directory…..IT RAN! And ran just fine. When I looked in the registry, all the keys I deleted were restored. Interesting to note that all the references to the ocx control in my installation are also to the network directory.

To recap, the installation is set to put the titext6.ocx control in the WinSysPath, yet it still insists on referencing it in the network directory. Deleting all references in the registry just re-creates those references back to the server.

There is one more thing that might be worth mentioning. I just generated another installation program using the PDW. In the Packaging Report it states at the end: “You have included mdac_typ.exe in your installation package. If you will be installing this package on a Windows 95/98 system, it will require DCOM98 to install properly.” I’m not sure what this means, or if it is important here. The program does install correctly on some machines, just not on the ones that matter.

Reply | Quote

Try leaving the “C:WindowsSystem” bit out.

Reply | Quote

It required the path

Reply | Quote