Differences between 'runtime' and 'full' besides the obvious?

[Girn13]

We recently converted from NT to XP and my dbs are exhibiting strange behaviors in the runtime version of access. Different applications on different machines and all references have been verified.

1. Runtime version ignores default printers while "full" version machines print to correct printer.
2. Closing two of the six forms opened from the base form cause a drop down box on the base form to go empty yet if you click on a line in the white area the patient data appears. It's like the forecolor of the dropdown area has been changed to white.
3. Clicking a command button to close the "enteractivity" form causes "enter parameter value " "forms!enteractivity!cmbBatchNo". That code isn't in the onclick for the command button and anywhere else I reference that dropdown box in code I include ".column".
And I can't reproduce these errors on my development machine even if I use /runtime. Do I have to rebuild these db's from scratch?

 

[ineuw]

Your problems are not unheard of and I would be curious to know what you updated to what and which OS are you using. Unfortunately, if you have updated to Office XP, the news are not good but I could offer tyou a few pointers.

 

[Girn13]

Thanks for answering but I'm sorry about the bad news. We went from Office 97 under NT 4.0 SP-2 to Office 2002 SP-2 under Windows XP Professional SP-1.
A question. Is there any way to determine, programmatically what version of a reference I'm using? I'm using MSCAL.OCX (version 10.0) but I can make the db crash by substituting MSCAL.OCX (version 8.0). The reference isn't BROKEN and the GUID's are the same. When I look at the references it says 8.0 or 10.0 but I can't see the references on the Runtime machines. Arrrrgh.

 

[ineuw]

Hmmm, Office 97 and NT4 The good old days. Now, here is what I do know. Install Office XP SP3 on your uncompiled version of your drive.

Office library 9 (Office 2000) is the most stable and it converts the 97 databases fine. You may consider doing an intermediate step of conversion 97-> 2000 -> XP

The MSCAL.OCX is a confusing issue. When I look at my installed Calendar's properties it says that it's version 7 but I don't care because I know it's version 8, it works fine in compiled and uncompiled modes.

If you use DAO, version 3.60 is also the most stable and reliable. If you use ADO, version 2.8 was released and can be downloaded from Microsoft and the file name is MDAC_TYP.EXE. (I believe that the native XP version that comes with a full installation, is 2.7). Also, there is another package you may consider installing mdac28sdk.msi.

If everything works well on your drive, uncompiled and runtime mode, check what libraries are installed in the users' workstations. Are they using the full version of Access as well? If they do, make sure that the libraries are there and that they are in the right folder. MS Office installation does misplace files. If not installed, you may have to expand it from the CD, and move it to the appropriate folder.

I hope this helps.

 

[Girn13]

Sorry for not getting back sooner. Thanks again for your interest in this issue. What angers me is that once we install the "Full" version on someone's box the problems disappear. I'm going to spend today re-creating one of the problem db's from scratch in XP and see if that alleviates the problems, which would then point the finger at the convert process. One post I read suggested taking a 97 db to 2000 then converting that to 2002. Rube Goldberg would've been proud.
I'll let you know what happens. Thanks again.

 

[ineuw]

Help may be on the way!!! If you are using runtime versions, I just saw yesterday an important patch for Access XP on the MS Office updates website. I hope this deals with some of your problems. Please let me know if it helped, and Good luck.

Signed
A satisfaction junkie