[RESOLVED] Activex Component Can't Create Object?

[joe426]

I created a program which connects to a database. I transferred over this program exe to another computer along with the database it reads/writes. But when I run the program, I get the error:

Activex Component Can't Create Object 429

What else do I need to transfer from the computer the program was created on to the computer the program will be used on? I used Jet to connect to the database.

Thanks!

[Hack]

How did you accomplish this "transfer"?

If you just copied the files over, that isn't going to work.

You need to make a formal installation and setup package, and have the resulting Setup.Exe run on each machine.

[joe426]

Yes, I just copied the files over. What do you mean formal installation and setup package? Install VB6 on the new machine?

[Hack]

No, no....not install VB6, install your program.

There is more to your program than just the exe file. There are dependency and run time files that your VB exe needs to be installed on the target machine in order to work. Creating a formal installation and setup package will accomplish this.

VB6 comes with such a tool. It is called the Package and Deployment Wizard. Have a look at this article.

[joe426]

Just went through the Package and Development Wizard and transfered the CAB and other Package files. Still doesn't work, gives me numerous error messages, says drivers are out of date, etc, etc when I tried to install it. Running the exe again yields the same

Activex Component Can't Create Object

[joe426]

Read up a lot on google, still can't get it working...Any other tips, suggestions?

[RobDog888]

You probably are missing some dependancy file(s) still. This is part of creating the setup package.

What is the build OS and what is the target OS?

Thread Moved

[joe426]

Both XP

[joe426]

Still can't get it to work...

[joe426]

Suggestions...Anyone? I'm stuck!

[dilettante]

Deployment is not a simple subject. Depending on what your program does it might not even be deployable: when you develop you have to make sure any non-system components you use are available in deployable form. The mention of "drivers" makes me suspicious in this case.

At the most fundamental level you need to know what your dependencies are and what their dependencies are, etc. Most application packages can scan your project to determine the first-level dependencies and from there may use different methods of determining sub-level dependencies.

Some system components are specific to the OS, even the specific SP of the OS version. Many of these are meant to be installed or updated via system updates and not by application setup packages, while others can be installed per-OS by some application installers.

Some came about in newer OSs after PDW was released, and so the PDW is not "smart enough" in a default installation to know when to avoid installing something and when to install an OS-specific version. You handle this by updating PDW's vbdep.ini file and redist folder, and sometimes you need different ones to target different OSs. You may also need to update or create the .DEP files matching each component library (.DLL or .OCX).


Simple programs may not encounter any of these issues, but in packaging anything exotic your chances go up.

Seeing the first part of your Setup.LST file might help us make suggestions, in particular the sections [Bootstrap Files] and [Setup1 Files].

[joe426]

Thanks for the response. The program is a checkin-checkout system which connects to a microsoft access database using jet 3.51.

Your requested sections of Setup.LST reads:

[Bootstrap Files]
[email protected],$(WinSysPathSysFile),,,6/18/98 12:00:00 AM,102912,6.0.81.69
[email protected],$(WinSysPathSysFile),$(DLLSelfRegister),,5/31/98 12:00:00 AM,22288,4.71.1460.1
[email protected],$(WinSysPathSysFile),,,5/31/98 12:00:00 AM,326656,4.21.0.0
[email protected],$(WinSysPathSysFile),$(TLBRegister),,8/4/04 5:00:00 AM,17920,3.50.5014.0
[email protected],$(WinSysPathSysFile),,,8/4/04 5:00:00 AM,65024,5.1.2600.2180
[email protected],$(WinSysPathSysFile),$(DLLSelfRegister),,8/4/04 5:00:00 AM,83456,5.1.2600.2180
[email protected],$(WinSysPathSysFile),$(DLLSelfRegister),,12/4/07 11:38:13 AM,550912,5.1.2600.3266
[email protected],$(WinSysPathSysFile),$(DLLSelfRegister),,8/4/04 5:00:00 AM,1392671,6.0.96.90


[Setup1 Files]
File1=@MDAC_TYP.EXE,$(AppPath),,,6/26/98 12:00:00 AM,8124720,4.71.1015.0
[email protected],$(WinSysPath),,$(Shared),4/3/00 6:52:54 PM,151552,6.0.88.4
[email protected],$(WinSysPath),$(DLLSelfRegister),$(Shared),5/11/00 2:06:20 PM,397312,6.0.88.62
[email protected],$(WinSysPath),,$(Shared),6/18/98 12:00:00 AM,89360,6.0.81.69
[email protected],$(WinSysPathSysFile),,,4/24/98 12:00:00 AM,407312,3.51.623.0
[email protected],$(WinSysPathSysFile),$(DLLSelfRegister),,4/24/98 12:00:00 AM,252176,3.51.623.0
[email protected],$(WinSysPathSysFile),,,8/4/04 5:00:00 AM,380957,6.0.72.9589
[email protected],$(WinSysPathSysFile),,,8/4/04 5:00:00 AM,30749,6.0.1.9431
[email protected],$(WinSysPathSysFile),,,4/24/98 12:00:00 AM,123664,3.51.623.0
[email protected],$(WinSysPathSysFile),,,4/24/98 12:00:00 AM,24848,3.51.623.0
[email protected],$(WinSysPathSysFile),$(DLLSelfRegister),,4/24/98 12:00:00 AM,1045776,3.51.623.4
[email protected],$(MSDAOPath),$(DLLSelfRegister),$(Shared),4/27/98 12:00:00 AM,570128,3.51.1608.0
File13=@Inventory System.exe,$(AppPath),,$(Shared),7/25/08 8:44:25 AM,45056,1.0.0.0

Thanks for your help.

[RobDog888]

Both XP

Makes no difference if they are both XP because oe my have dependancy file(s) installed from some other software while the other may not. Deploying a program always requires a setup program with all needed dependancies. Anything else is just asking for a program crash

[joe426]

How can I figure out what my programs "dependency" files are so I can transfer those to the new machine and get the program working?

[dilettante]

It appears that your program requires Jet 3.5, some old version of MDAC with DAO, and even more eerily RDO. This is all junky old stuff dating back to when VB6 was released in 1998, with the recommendation to stop using it even then!

The other oddity is apparently something called "Inventory System.exe" which is probably an ActiveX EXE of yours?

Most of this should still be deployable to a WinXP system but might not work in Vista. Those ancient database connector components are only partially supported under Vista.

One thing you might try is to go back into PDW and this time "uncheck" everything except MDAC_TYP and your "Inventory System" EXE. Ok, maybe leave in all of those "bootstrap files" except MSVCRT40.DLL (never try to deploy these VC runtimes, they've been tailored to the OS for a long time now).

If the MDAC_TYP.exe that is in your PDW's redist folder is ancient enough it may have all of those Jet 3.5 and DAO/RDO pieces in it.

Of course you have to run the resulting installer package over on the target system too.


If you have the option at all though I'd recommend that you do a rewrite. Hopefully the program's database access logic is somewhat isolated, making a rewrite less of a burden. Avoid DAO and RDO like the plague, use ADO if at all possible. If you must use DAO, use DAO 3.6 and not the truly ancient DAO 3.5. Avoid the really old DAO 3.5 data controls in VB6. Move to Jet 4.0 at all costs - it's been around for almost 9 years now.

This sort of thing is the risk you face if you install VB6 clean and don't do all of 10 years of manual updating to the development package... and you program according to old books and code samples.


This is the burden we faced when .Net came along and killed the VB franchise. If we'd ever gotten a real VB7, VB8, etc. over the years we wouldn't have these problems because everything would have been updated as Windows evolved. Your alternative is to move to .Net, which may or may not be viable for you.

[joe426]

Awesome! It works. I did have to uncheck those files as you said. I also forgot to go through the dependency file wizard last time (not sure if that made the difference). Anyways, thanks for the help, I appreciate it.