December 13, 2010 Leave a comment
This one left me scratching my head for quite some time.
Over the years, I’ve written a number of Access ADP modules which act as various front ends for our database. Each of these modules has a different focus depending on the target user (shipping, admin, etc). Users are running Access Runtime and compiled ADE modules.
These modules are installed using an install package created in VB6. The packages contain the version of the module that was current at the time the package was built. I haven’t updated the packages as I have a shell script exe that checks for the latest version of the ADE. If there is a new version, it copies the file from the server to the local directory and launches that. There’s never been an issue with it. Until recently.
A couple of months ago we upgraded a good portion of our desktops to Windows 7. We ran the appropriate module installation routines for users and all went well except that one user reported a screen he was unfamiliar with and that most of the features he was used to were missing. I had a look at this and sure enough, when I launched the file the module was the wrong one. This happens when using either the vb shell script exe or by copying the latest ade and overwriting the file that is in the Modules/Admin directory and manually launching.
Imagine my frustration when I can open the file from \\server\databasedistribution and it is the correct version . Then I copied the exact same file I just opened (on the server) to c:\program files (x86)\modules\admin. I launched the file and the version is wrong. I tried deleting the local file copying the new one. Same result.
The file that is launched is the version which gets installed when the install script is run. No matter what I did, it would not launch the correct version. I couldn’t reproduce it on my system either. Nothing seemed to help and I was at a loss. Fortunately, this user did not use the module much in the first place, so I shelved it.
Last week, I upgraded someone who uses admin a lot and she had exactly the same problem. No putting her off, I had a look at the issue again this morning. This time I had the idea to search c:\ for admin.ade. I got multiple hits; one of them in her roaming profile. I deleted all but the one in the correct directory, launched it and woot – correct version!
For some reason, the roaming profile was grabbing that originally installed file and launching it even when the user was launching the updated file. Perhaps more bizarrely, the 6 other modules installed in the exact same way for 2 dozen users showed none of this behaviour. Why this would happen, I have no idea, but at least I know how to fix it. And now so do you.