trouble updating Access .ade or .mde with Windows 7 workstations sometimes

I'm an Access developer. In several different environments I'm actively working on Access programs running against SQL databases. I've been doing version control by simply copying the .adp or .ade or .mde file from the server to the user's workstation when the user logs on. I'm running into problems doing this with Windows 7 sometimes.

It seems Windows 7 gets one or more cached copies of the program saved somewhere, then keeps launching those. Even though there's a shortcut on the user's computer that points to the folder that has the newest version of the Access program file, the old cached copy keeps running.

I seems I'm more likely to encounter this problem if the Access program file is part of an runtime installation and is saved in C:\Program Files\AppName. But it still doesn't always seem to happen.

What are other people doing to solve this problem?
LVL 4
GordonPrinceAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
Leigh PurvisConnect With a Mentor Database DeveloperCommented:
Can I run screaming from that topic? :-p

UAC causes this knee jerk reaction of hating it when you first use Vista/7 and then coming to terms with it and then hating it again when you realize what a total PITA it becomes when distributing software updates. (Installations can write to Program Files - file replacement actions, especially initiated from a running application, can easiy be intercepted. :-s)

UAC is Microsoft's security model in Windows now.  I doubt that will change.
Every IT dept will have a different take on it being disabled (at least in Win 7 you can "turn it down" with more granularity) but ultimately - the fact that it might be running on a target PC is enough of a problem.
Hence, reluctantly, more and more are moving away from Program Files as an install location.  Which - to my mind - is pure insanity, as that's surely exactly what it's for.  But I like things that work most of all. :-s

Maybe have a read of this and see what you think.
http://msdn.microsoft.com/en-us/library/bb756973.aspx

Cheers.
0
 
Jim Dettman (Microsoft MVP/ EE MVE)PresidentCommented:

 Sounds like branch caching might be at work; is a Windows 2008 R2 server involved?

Jim.
0
 
GordonPrinceAuthor Commented:
No, the servers are all 2000 or 2003.
0
Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

 
Leigh PurvisDatabase DeveloperCommented:
It sounds like UAC Program Files virtualisation.
(i.e. copying the file to that location has actually replaced a version in the Users folder - where UAC virtualises Prog Files out to).
The original remains in that location and is subsequently launched again.
Installing to somewhere other than this (IMO overly) protected folder (somewhere off the root of C is often recommended) or saying bye-de-bye to UAC might be options?
0
 
GordonPrinceAuthor Commented:
What are the pros of having UAC and the cons of disabling it (other than this caching issue)?
0
 
GordonPrinceAuthor Commented:
The article seems to be discussing the issue I'm having, but I don't know what the solution is. I'm doing steady work and frequently have daily updates of the Access project that users are supposed to implement. Often there are 1-2 users requesting a feature, I program it, we install it on their computer and test it. Then it's available for everyone. People get new copies of the Access file when they log on, or by double-clicking a shortcut on their desktop that runs a copy script.

Seems to me my file copy script just needs to look in all the places I've ever found my Access file cached and delete those copies, too. Then replace the file in the "Program Files" folder and let Windows 7 recache it the first time it's used, etc. In most of the places I'm working, users are administrators of their own workstations.

Each domain could be different, but they wouldn't change very often, so I can probably just keep updating the scripts. Then when Windows 8 comes out, I'll update other scripts.

Unless you have some other thoughts.
0
 
Jim Dettman (Microsoft MVP/ EE MVE)PresidentCommented:

 I never even thought of UAC, I always turn it off<g>.

Jim.
0
 
Leigh PurvisDatabase DeveloperCommented:
>> I always turn it off <g>.
I'd love to Jim, but occasionally we have to just give ourselves the cold that clients might have. :-s
I have it "low" but keep VMs to test it full blooded.  (And it rarely goes the same way as it does for some client sites - so it's also slightly inconsistent. :-s)

>> but I don't know what the solution is.
That's just it - there is no panacea for this AFAIK.  (Given that you're already installed on Program Files.)
Every application that I have an installer for which used to aim there now points to a folder off the root of C.  Not at all what I wanted to do - but honestly, the potential for UAC interfering with updates hasn't left much choice.

Deleting cached versions - I'm not convinced how productive that will be.  There is still a real Program Files folder.  It's not entirely virtualised.  Only for your user based actions.  So there will still be protected (relatively protected as far as file actions go anyway) files there.  Replacing your User files in the quasi-virtualised locations will do just that.  If a shortcut launches the genuine Program Files file - then that's what it does.

I say give your plan a test.  See how it goes.
Back in early Vista days, users and companies were more amenable to UAC being switched off - which can be scripted.  But that is an extreme solution as far as some IT depts will be concerned.

Instead of just copying a file, executing a small install package which will write to the genuine Program Files location is perhaps one option.

Cheers.
0
 
GordonPrinceAuthor Commented:
What I'm encountering is that when the user double-clicks on the shortcut that points to the file in "Program Files", they get the cached copy of the program, not the new one that I put into "Program Files". If I do a search for all the instances of my Access project file on the computer's C:\, I get one or two other copies. If I delete them, then double-click on the same shortcut, the new (now only) version of the file opens.

But I'm intrigued by your idea of using another folder off C:\. Would making my installer program install the program to "C:\Tekhelps\" instead of "C:\Program Files\" get around this problem?
0
 
Leigh PurvisDatabase DeveloperCommented:
Interesting that it's launching the cached (virtualised location) copy.
But the problem, surely, is getting that latest version into Program Files in the first place.  OK, you have in this instance - but generally your file copy actions in your script/applications will result in the file deposited into the virtual location... :-s

And yes, IME moving the whole shebang to another location is a full solution.  (As it's only Program Files which is virtualised away by UAC.)
0
 
GordonPrinceAuthor Commented:
Maybe the "latest version" issue is failing if
1. I send a new version of the Access project to the server, then
2. later the user closes everything & reboots. Closing their older version of the Access project may update the date/time stamp on it.

So even though they've logged on and gotten a newer version of the Access project from the server, if the date/time stamp on the older version that's in their cache is newer than the date/time stamp on what's in Program Files, they keep running the version from the cache.

Maybe.

But if using a folder outside of "Program Files" solves the problem, I may go in that direction.
0
 
Leigh PurvisDatabase DeveloperCommented:
Hi
I'm not sure what you're saying about the versioning issue.  It sounds like you're talking about your own file version checking based on dates and code decisions being made based upon that?

Ultimately - your code methods can't replace the Program Files file while it's being "protected" by UAC.  That's the ultimate problem and required goal - and what going away from Program Files and into another location (such as off the root of C) circumvents.
0
 
GordonPrinceAuthor Commented:
I updated my logon script and it deletes the project.adp file from the user's cache -- if they're using Windows 7. That seems to have worked.
0
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.

All Courses

From novice to tech pro — start learning today.