Application attempts to install Access 2000 Runtime

I have a vb6 application that is distributed to a client machine. The client machine is windows XP with Access 2003 installed. The application runs fine, except when some of the forms load and load data from an Access database, the application attempts to install Access 2000 Runtime. I can cancel the install window and the appliction continues to run fine. What would cause this problem to occur? Would it have to do with dependencies or references in the deployment package, setting up the DSN, etc?
Gary2397Asked:
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.

fostejoCommented:
Gary2397,

An MSI based application (such as the Access 2000 RT) will behave like this if they detect that one of their 'components' isn't as expected (which usually means missing but could also mean that the version has been downgraded by another non-MSI based install for instance)

At the same time as the self-repair kicking off an event should be written into the Application event log saying exactly why the MSI is self-repairing. The event ID is usually '1001' and the description will probably be along the lines of:

"Detection of product 'chalice', feature 'FeatureName' failed during request for component '{D2D7B4BF-6DDA-11D5-8B3F-00105A9846E9}'"

The component ID referenced is the actual item that's 'missing' (or damaged or the incorrect version) on the machine - the ID directly refers to one of the components in the applications MSI and establishing which particular component it is will allow you to identify the other potentially rogue app that's also distributing it incorrectly etc.

cheers,
0
Gary2397Author Commented:
Could you explain this a little more, I am a little unclear:

At the same time as the self-repair kicking off an event should be written into the Application event log saying exactly why the MSI is self-repairing. The event ID is usually '1001' and the description will probably be along the lines of:

"Detection of product 'chalice', feature 'FeatureName' failed during request for component '{D2D7B4BF-6DDA-11D5-8B3F-00105A9846E9}'"
0
fostejoCommented:
Gary2397,

No problem; Immediately after the issue occurs, open up the Event Viewer on the machine (Start/Run.. and 'eventvwr') and look in the 'Application' Log and one of the most recent entries should relate to the self-repair of the Access 2000 RT and also give some idea as to why it felt it needed to self repair (BTW, ignore the reference to 'chalice' in the original post, it'll actually refer to the Access RunTime!)

If you find the appropriate entry, but still can't fathom what it means, please paste the Event description here.

cheers,

0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Gary2397Author Commented:
I did just as you said, and this is what came up with:

Detection of product '{00180408-78E1-11D2-B60F-006097C998E7}', feature 'AccessRuntimeMaster' failed during request for component '{1D2B754A-CD9A-11D1-8279-00C04FC21633}'

Now, I have to research this.
0
fostejoCommented:
Ok .. I beleive that particular component is 'Global_Vba_VBStandardFormat' which is actually the physical file 'MSSTDFMT.DLL' in your system directory (c:\windows\system32 generally)

In theory, if you take a note of the size, date/time stamp and also the version of this file (by right mouse clicking it,selecting 'properties' and then the 'version' tab) you should see it get replaced by a different version when the Access RT fixes itself.

However, it's worthwhile investigating what other application may be replacing the file so that the Access RT feels it needs to 'fix' it - in other words identify the actual root cause of the issue.

It shouldn't be another MSI as they *should* be authored to correctly handle versioning mismatches, so it's likely to be a legacy application install overwriting 'msstdfmt.dll' when it shouldn't be - does the vb6 application distribution you're installing contain 'msstdfmt.dll' ?

cheers,
0
Gary2397Author Commented:
Yes, the distribution package does include the msstdfmt.dll.
0
Gary2397Author Commented:
I should have listed this earlier, but just saw it in the event log.

This is the error thrown before the above mentioned error:  

Detection of product '{00180408-78E1-11D2-B60F-006097C998E7}', feature 'AccessRuntimeMaster', component '{8ADD2C98-C8B7-11D1-9C67-0000F81F1B38}' failed.  The resource 'HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Access\UserData' does not exist.

0
fostejoCommented:
You've not said, but I presume that this only occurs when the vb6 application is *first* ran (however, if you cancel the 'fix' dialog, it occurs each time it runs?)

If that's the case, then it's very likely that your VB6 distribution is overwriting an *existing* version of msstdfmt.dll when it shouldn't be doing (hence the Access RT MSI 'fixing' it when the 'damaged' comes to be used)

The only real solution is to correct your VB6 application distribution so that it doesn't push out the file at all (it's bad practice to deploy system DLLs via an application deployment anyway) or only push it out if it doesn't already exist or is a lesser version (though I think the VB6 PDW should do that anyway...?)

However, before doing this, you'll need to understand what's already installed on the target computers - I'm not sure whether msstdfmt.dll is a DLL installed as part of the base O/S or whether it's installed as part of MS Office for instance.  If it's already on one of your clean freshly installed machines (if you have a 'standard' image) then you shouldn't have any issues removing it from your VB6 distribution..

Good luck..
0
Gary2397Author Commented:
Yes, when i cancel the Windows Installer dialog, the problems persists each time the application is executed. I presume you are using the 'fix' dialog to refer to the 'windos installer' dialog that attempts to install Access 2000. I checked the version of the msstdfmt.dll on my machine and it is 6.1.97.82, this is the same version being installed the the instller package. I re-created the installer package and excluded the msstdfmt.dll file and the same error persisted.
0
fostejoCommented:
Ah ha.. only just seen your comment at 10:03 regarding 'HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Access\UserData' ... it could be that msstdfmt.dll is a red-herring.  In the last test you did (after excluding it) did you get the same event logged in the application log that you pasted at 08:41?

If not, then it may just be that everything is actually 'working as designed' - it's just that the Access RT component that's being referenced by your application *needs* to create some specific data for *each user* of the application (which is why it attempts to write to HKEY_CURRENT_USER rather than HKEY_LOCAL_MACHINE)

If this is indeed the case, then I'd suggest just leaving it as is as it's likely that the data it writes to the registry key is perculiar to the currently logged-in user and - as long as you don't cancel the dialog - it should only need to 'repair' once for each user of the application on a given machine.

(However, my earlier comment about removing the system DLLs from your VB6 distribution is still valid!)

cheers,

0
Gary2397Author Commented:
I have fixed the error. Let me tell you how I did it. I want to give you the points, becuase you led me in the right direction.

First of all, to address the above post: When I let the installer run through (install Access 2000 Runtime), I later develop an error in the application that will not allow me to view an Access report that I call and open from the application.

Now, for the fix: In the above error: Detection of product '{00180408-78E1-11D2-B60F-006097C998E7}', feature 'AccessRuntimeMaster', component '{8ADD2C98-C8B7-11D1-9C67-0000F81F1B38}' failed.  The resource 'HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Access\UserData' does not exist.

I went to Start - Run - "regedit" . And manually created:

[HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Access]
"UserData"=dword:00000001

And

[HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Common]
"UserData"=dword:00000001
"OSAShortcut"=dword:00000001


And I executed the application, without the Installer window appearing and I can open and view the Access Reports.

Could you tell me why I had to do this, or why this worked, and I will be glad to give you the points.
0
fostejoCommented:
Hi Gary2387,

One much touted feature of an MSI is its ability to self-repair, which is what you've been seeing take place.

Basically, an MSI is made of numerous 'Components' (each representing one or more files, registry or ODBC entries), arranged in one or more 'Features' (which corrospond to the selection of Components to install for a 'Complete' or 'Custom' installation for instance)

During the creation of the MSI, each Component is assigned a 'Key Path' by the author which represents a file or registry entry which the author considers critical to the correct functioning of the application - in general, this is a file or registry entry which must be present or of a specific value/minimum version.

For the above issue, the MSIExec engine detected that 'HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Access\UserData' didn't exist and - had it had been set as a Key Path in the Access RT MSI - self-repaired. The self-repair would have re-installed the affected Component (therefore creating the missing registry entry as part of that Component re-installation) and also checked all of the other Key Paths just in case.

The next time the Key Paths are checked, if all the checks are passed, the application won't bother self-repairing and you'll not see the Windows Installer dialog (nor get an Event logged) - which is what happens once the repair is left to complete.

That explains why the Windows Installer dialog is now longer shown and I suspect (but can't confirm for certain) that the OSAShortcut/UserData DWord values are basically a 'marker' to indicate to the Office / Access RT installation that its gone through and completed some specific installation/configuration step (such as the user entering their ID and initials at first launch for instance)

For a fuller explanation of the MSI self-repair etc. have a look at http://www.answers.com/topic/windows-installer

cheers,
0

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
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.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.