I have an app I am trying to deploy. Its built on a Win2000 development machine using Access2002, split into front end/back end. Front is an mde, back is an mdb. Shipping with Access2002 runtime since clients may or may not have Access installed, any that do, probably will not have Access2002.

Current problem is that I built an install package and ran it on a win98 system loaded with full version of Access2000. I dont believe there is anything special about the fact that I installed on a win98 box, the system stuff that I'm missing isn't on the install media anyway.

The Access2000 version of the app was installed on this system months ago and is still running fine. The new version calls Access2002 and loads, uses the current version of the app but has odd problems. First problem noticed was #Name? in text fields loaded from date register. Found the ActiveX reference used in development (2.6) was not installed, system still had the previously existing 2.5. Manually replaced that with 2.6 copied from development and dates are now fine. Other problems are now forms that are not filtered correctly, code apparently choking on null values, on and on.

Looking at other references on the development system, I only use 5...VBA, Access 10, OLE, ActiveX 2.6, DAO 3.6. None of these are on the installation set. The target system still has DAO 3.5, Access 9, etc.

My questions center on how to get the required things onto the install media. I thought "Include System Files" pretty much covered it. If I force them on as dependencies, I have no idea what their target directory might be. I don't think I can deal with separate install media for every possible client system. No one else in the software world seems to. Should the packaging wizard be dealing with these or is there another process I must do?

With all the directory structures used between various versions of win 98, 98SE, Me, NT, 2000, XP...I don't know how I could I ever know to include them manually and where to update them to on the target machine. I don't know how I would even know what things should be included. Surely there are people out there creating access apps for distribution to various client systems? right? I can't be the only one even though I feel like it, right?

Did you ever get a solution to your question? If not, I have some thoughts, as I have been fighting the same issue. In the end, I have a scheme that I *think* works, though I haven't beat on it enough to swear for sure (which is why I'm not going to post it as "the truth").

Yes, I did get an answer. After arguing for three days over how much Microsoft was going to charge me to answer the question, it came down to this: The deployment wizard does not include the Microsoft Data Access Components necessary. You must add mdac_typ.exe to the files deployed. Ok, I thought, then I'll run that at the end of the install (where the wizard says "run this command when the installation is finished"). Wrong. With MS Support on the phone, we could not make that happen. I now have two separate installs...the users must run setup.exe, then they need to browse the CD to the Support directory, find mdac_typ.exe and run it. Of course they miss this piece about 40% of the time. I think I can make a script to run this, I haven't had time to do one that will reliably locate the CD (what drive is it?). Any script-masters out there, I'd love to see a sample to help make a reliable script for this...

You're experiencing some of the reasons most of us prefer not to use the PDW. Consensus is that the Wise Installer and SageKey scripts, while a little pricey, are worth their weight in gold. I gave up on Microsoft's setup tool years ago when I discovered that a setup I built on an NT machine wouldn't install properly on a Win95 box. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>