VB6, Win98, WinXP and VBAJET32.dll

I've built a tiny app that use an Access97 database.
All the app uses the "stardard" ADO "Data" control (the one that's on the toolbar by default.
I'm developing and compiling under Win98SE, and all works great.
I don't like the Setup builder that comes with VB, so i use it only to know what DLLs my app needs, that i copy "by hands" my app and the mdb file on the customer client, that haves WinXP Pro.

I obtain an error saying that the VBAJET32.dll can't create objects (is a error i trap in my app), so non can works.

What happens?
How can i make my app running (read/write the database) on Win XP?
If i make a Setup (9 floppies for a 80k app and a 100k mdb!!!) i will solve the problem, or i can make the customer PC not working 'cause old versions of the DB dlls?

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Try this:

Get the latest MDAC from MS

Try using the Visual Studio Installer.  It's FREE.  It makes smaller install files than the P&D Wiz.  It's FREE.  And it gives you more control over the install process.  Did I say It's FREE!!!
Are you using Access objects or in other words Access Automation in your application? If that is the case then your application would require Access installed on XP. I dont see you problem as MDAC problem as XP comes pre installed with MDAC 2.7 Refresh.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Actually I meant update MDAC on the build machine not the clients.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

He is not facing any problem in the development machine. Had there been any problem with MDAC in development machine there would have been errors there.
Way to speak for the guy. But as he said.  Win98Se and hand coping files.  That smells like trouble to me.  Could be grabbing files not compatible with XP.  Trust me, I'm a programmer and I do support for our app.  Win98 is not the ideal build environment (not to put you down fab1970)  but since fab1970 has yet to comment. Ill wait to see before I make assumptions, only recommendations!
fab1970Author Commented:
UH! You guys are fast!
1) Sorry about an error: the "Data" control uses DAO, not ADO, is it right?
2) blkbam: why Win98 is not an ideal build environment? I (and a half world, i think) have developed on it from years, running developed apps on WinNT, 98, ME and 2000. I'm very courious about this...

Anyway, that's my first encounter with WinXP (believe me, i've never seen it before).
with "hand copying files" i mean:
i make a folder and put in it the EXE and the MDB file.
Do a check on the system to see if the DLLs the Wizard tells are needed are in the system.
(i also use the Dependecy Walker that comes with VS6 for that purpose...)

If i can't find it, then i copy the missing DLLs in the system, eventually registering it with RegSvr32.
I do that from years... never found a case where i need to use that ugly Setup...

In this specific case, all DLLs are already in the WinXP PC, that also have Access2000 installed.
I was expecting some "code" error (developing in Win98 and debugging in WinNT teach me a lot about different behaviour with the same code), but the apps starts right (it check in the regestry for settings).
When it try to open the Database file i put in the Data.DatabaseName (or maybe the RecordSource?) then i have that error about the VBAJET32.dll.

I've tryed to put the app in a clean/fresh installed WinXP, and i have a "ActiveX can't create object", that is exactly what i'm expecting....

I will try after this post with a Setup (4 AM here, sigh!) instead of my Hand copy...

So,  i think the problem is the DLL version... or not?

You are using DAO. MDAC doesn't contain Jet engine anymore. Look at this link:

So all you need to do is install Jet engine on XP and that should be the end of your problem.
fab1970Author Commented:
DAMN! I've seen that MS page, and following the link http://support.microsoft.com/default.aspx?scid=kb;EN-US;239114
i've downloaded  WindowsXP-KB829558-x86-ENU.exe...

...witch refuses to install 'cause the language is not the same (i've an Italian version of XP).

Do you know where to find the ITA version?
I'm not able to find it (maybe is time to sleep ;(  )

Install the EXE mentioned in the link above then install the following service pack and choose Italian as language:

The best way is to use ADO instead of DAO so that you just install mdac to the system
No doubts about it.
fab1970Author Commented:
Well, i've found the ITA sp8 for JET4.0 for XP.
Installed... problem is still present.
Then dowloaded and run the Visual Studio Installer(under W98), installed on XP.... problem is still present.
Then Installed the SETUP made by the VB wizard (a single 9MB Cab file for a 150KB app... wow!), getting a couple of version conflict (keeped the XP ones)...
all runs fine.

This is the lst file:
SetupText=Copying Files, please stand by.
CabFile=BB Magazzino.CAB

[Bootstrap Files]
File1=@VB6STKIT.DLL,$(WinSysPathSysFile),,,7/15/00 12:00:00 AM,101888,
File2=@COMCAT.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,5/31/98 12:00:00 AM,22288,4.71.1460.1
File3=@MSVCRT40.DLL,$(WinSysPathSysFile),,,6/1/99 12:00:00 AM,326656,
File4=@STDOLE2.TLB,$(WinSysPathSysFile),$(TLBRegister),,6/3/99 12:00:00 AM,17920,2.40.4275.1
File5=@ASYCFILT.DLL,$(WinSysPathSysFile),,,3/8/99 12:00:00 AM,147728,2.40.4275.1
File6=@OLEPRO32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,3/8/99 12:00:00 AM,164112,5.0.4275.1
File7=@OLEAUT32.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,4/12/00 12:00:00 AM,598288,2.40.4275.1
File8=@MSVBVM60.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,8/21/00 12:00:00 AM,1388544,


Icon1=""BB Magazzino.exe""
Title1=BB Magazzino

Title=BB Magazzino SETUP
AppExe=BB Magazzino.exe
AppToUninstall=BB Magazzino.exe

[Setup1 Files]
File1=@Magazzino97.mdb,$(AppPath),,,10/22/03 3:55:10 AM,196608,
File2=@MDAC_TYP.EXE,$(WinSysPath),,$(Shared),1/20/00 12:00:00 AM,7856352,25.0.4403.12
File3=@RDOCURS.DLL,$(WinSysPath),,$(Shared),8/2/00 12:00:00 AM,151552,
File4=@MSRDO20.DLL,$(WinSysPath),$(DLLSelfRegister),$(Shared),8/2/00 12:00:00 AM,397312,
File5=@MSEXCL35.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,4/24/98 12:00:00 AM,250128,3.51.623.2
File6=@VB5DB.DLL,$(WinSysPath),,$(Shared),6/18/98 12:00:00 AM,89360,
File7=@MSREPL35.DLL,$(WinSysPathSysFile),,,5/5/99 10:22:00 PM,430080,3.51.2404.0
File8=@MSRD2X35.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,4/24/98 12:00:00 AM,252176,3.51.623.0
File9=@expsrv.dll,$(WinSysPathSysFile),,,10/12/03 9:26:42 PM,379152,
File10=@VBAJET32.DLL,$(WinSysPathSysFile),,,5/5/99 10:22:00 PM,30992,
File11=@MSJINT35.DLL,$(WinSysPathSysFile),,,4/24/98 12:00:00 AM,123664,3.51.623.0
File12=@MSJTER35.DLL,$(WinSysPathSysFile),,,4/24/98 12:00:00 AM,24848,3.51.623.0
File13=@MSJET35.DLL,$(WinSysPathSysFile),$(DLLSelfRegister),,5/5/99 10:22:00 PM,1056768,3.51.2723.0
File14=@DAO350.DLL,$(MSDAOPath),$(DLLSelfRegister),$(Shared),4/27/98 12:00:00 AM,570128,3.51.1608.0
File15=@BB Magazzino.exe,$(AppPath),,,10/21/03 2:21:30 AM,278528,

Note that all these files already was present on the system of my customr....
One has to live with ugly side of Micrsoft ;-)
fab1970Author Commented:
"You don't know the power of the dark side of the MSoft, Luke..." HEH :D

blkbam: are you still reading here?
Can you explain (teach?) me your phrase about developing on Win98?

Sethi and ADDYKT: I mostly work in/with microelectronic... why ADO is better than DAO?

I was starting with the DB Wizard, that generates a bunch of ADO code ... it was (for my eyes) a lot of things to manually manage for a tiny app like the mine... and "standard" components don't works with ADO...
(one of my goals is everytime to avoid (if possible) OCXs; so i always use APIs for file dialogs, for example...)
Search msdn and you will see umpteen no. of benfits of ADO as compared to DAO, Infact you can serach google and you will come out with umpteen no. of links.
Use ADO is guaratee you can port to next windows version but DAO is not

MS will not spend any time on DAO to do modification and fixed

However for the speedwise, DAO is faster than ADO since DAO is designed for Access only
It is faster only till version 97. With version 2000 and 2002, Microsoft started concentrating on ADO.
I have not seen any performance doc talking about this

but you can imagine that DAO access ACCESS database directly while ADO is going through OLEDB server. There is extra layer in between
Here's an article, (which you can't read unless you're a member, sorry) but the compile process relies on the OS to determine how the app will be built.  I'm don't know how your app is coded but certain dlls are only specific to certain OS's.  Since you're using a 16-bit OS trying to run software on a Semi-True 32-bit OS, a function on the Win98 machine may not behave the same on WinXP.  This is why some apps are distributed with a version for 95/98, NT/2K, and XP.  The grouping is because they share the same kernel and for the most part, the same underlying technology.


Just in case you're wondering, by "Semi-True" I mean that XP is not a true 32-bit OS because it still contains support for 16-bit applications and some parts of it still run in a 16-bit process.
fab1970Author Commented:
Well, seems time for me to learn something about ADO... and maybe to close this question...
But i'm in difficult... techically, the question is still unanswered (i solved my problem building a Setup with the VB Setup wizard, that was what i would like to avoid!)...
My big problem is: all dll was already on the system ('cause Access2000 was already installed)... so what Setup do?

I can keep this question open for other comments, or close it if you says "No more suggestions" or "It was simply impossible to do by hands"...

Tell me something, mates...
I hope you are using ADO now. All controls did to be registered, the best way is to use the install setup package wizard
on VB
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
No response from fab1970 from 10/23/2003 comment
Award points to Sethi(50%) and EDDYKT(50%) is recommend.
Please leave any comments here within the next seven days.

EE Cleanup Volunteer
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.