When you run the PDW, make sure that you have MDAC in there somewhere - it has all the ADO stuff your user will need.
(It'll also make your package much larger unfortunately!)
Printable View
When you run the PDW, make sure that you have MDAC in there somewhere - it has all the ADO stuff your user will need.
(It'll also make your package much larger unfortunately!)
I don't think you can get around the MDAC issue.
Not if you want to interact with databases. :)
It would be nice if MS would just package the data access components individually, so if you just wanted ADO you could just include ADO. However, I'm sure they have their reasons.
The only other way (not nice) if you know that the user will have Access 97 on their machine, you could revert to using DAO to do your data-handling. Seems a bit of a retrograde step though...
Pete - is it possible to put all the program on one package and the mdac and other references possibly required in another. Then if it installs and works - great. If not they have to get the huge file and run it...
I was looking at the same sort of problem, but since I can't use VB at work (cause I haven't broken the ahem *coughrulescough* yet) I didn't go any further. But I needed the DAO stuff onto a comp with none and my db exe was 1 mb already so add to the DAO was three or four floppies of zip file.
Vince
Yeah - there's probably no reason why you can't ship MDAC_typ.exe separately - it is a standalone install package.
I don't know this for a fact, but it seems reasonable.
my user wouldn't d/l big MDAC to run small :(