David McAfee
davidmcafee at gmail.com
Fri Feb 27 11:50:34 CST 2015
I do something similar to what JC does, but I don't copy over every time. I number each mdb and check the network version versus the users current version. If it is different, copy it over and launch, otherwise just launch the local copy. I check for different rather that greater because it's possible that a version has to be rolled back. I originally wrote the launcher in vb.net then rewrote it in c#. Works great. On Feb 27, 2015 7:45 AM, "John W. Colby" <jwcolby at gmail.com> wrote: > I used a simpler method. A batch file on the user's machine just copies > the FE down from a server location to the local machine and fires it up. > If I make a change I place the new version in that dir and tell everyone to > get out and back in. This does mean that everyone always copies the file > every time they start the app but the overhead isn't usually so great that > it makes a huge difference. > > John W. Colby > > On 2/27/2015 10:34 AM, Heenan, Lambert wrote: > >> My update process works as follows: >> >> The application front end has a table which holds the version number. >> When it starts up the application looks at a particular folder where the >> most recent version sits and checks if the version number is greater than >> the one the user is currently running. >> >> If there is a new version, the application then calls an existing >> vbscript which is stored in the same place as the application latest >> version file. The running, older copy of the application then shuts itself >> down. >> >> The vbscript then checks the folder where the user's copy of the >> application resides and sits in a loop waiting for the laccdb file to >> disappear. When that happens the script then copies the new version into >> place and launches it. >> >> >> If the loop waiting for the lock file to go away takes longer than 60 >> seconds it gives up and displays a message to the user. >> >> >> Lambert >> >> -----Original Message----- >> From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces@ >> databaseadvisors.com] On Behalf Of Janet Erbach >> Sent: Friday, February 27, 2015 9:45 AM >> To: Database Advisors >> Subject: [AccessD] Automatic Update Function >> >> Hello all - >> >> Do any of you have a favorite approach/module that you use to >> automatically update the front end on the user's machine? My monster >> application from WIFI hell has had auto update issues as well as corruption >> issues. >> >> My co-worker that developed part of the app with me wrote an auto update >> module that >> >> Creates a batch file on the fly >> Closes Access >> Runs the batch file to copy the new front end to the user's machine and >> then re-opens access >> >> At least that's what's supposed to happen...there have been a number of >> times that I've been suspicious about whether or not this auto update is >> somehow triggering back-end corruption too, although I don't know why it >> would. There have been many times when the app is up and running fine on >> 10 machines and when the 11th machine starts up and goes into auto-update >> mode the whole thing comes crashing down. Maybe that's just coincidence. >> >> BTW, I'm implementing the 'write to CSV' option today to try and stop the >> corruption... >> >> Janet Erbach >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >> >> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >