Solved

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

Posted on 2011-09-13
13
415 Views
Last Modified: 2012-05-12
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?
0
Comment
Question by:GordonPrince
  • 6
  • 5
  • 2
13 Comments
 
LVL 57
ID: 36529283

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

Jim.
0
 
LVL 4

Author Comment

by:GordonPrince
ID: 36529440
No, the servers are all 2000 or 2003.
0
 
LVL 44

Expert Comment

by:Leigh Purvis
ID: 36533019
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
 
LVL 4

Author Comment

by:GordonPrince
ID: 36535101
What are the pros of having UAC and the cons of disabling it (other than this caching issue)?
0
 
LVL 44

Accepted Solution

by:
Leigh Purvis earned 500 total points
ID: 36535133
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
 
LVL 4

Author Comment

by:GordonPrince
ID: 36535714
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
6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

 
LVL 57
ID: 36535744

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

Jim.
0
 
LVL 44

Expert Comment

by:Leigh Purvis
ID: 36536137
>> 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
 
LVL 4

Author Comment

by:GordonPrince
ID: 36536711
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
 
LVL 44

Expert Comment

by:Leigh Purvis
ID: 36537151
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
 
LVL 4

Author Comment

by:GordonPrince
ID: 36537291
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
 
LVL 44

Expert Comment

by:Leigh Purvis
ID: 36537850
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
 
LVL 4

Author Closing Comment

by:GordonPrince
ID: 36556022
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

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

Suggested Solutions

Introduction The Visual Basic for Applications (VBA) language is at the heart of every application that you write. It is your key to taking Access beyond the world of wizards into a world where anything is possible. This article introduces you to…
Describes a method of obtaining an object variable to an already running instance of Microsoft Access so that it can be controlled via automation.
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now