Dan Waters
df.waters at outlook.com
Mon Mar 2 10:14:07 CST 2015
Several few years ago I needed to create a method to be sure my customers go the latest file. This is how I did it. 1) In my app, I made a table named 'tblLatestUpdate' which has just one row. A date column is named 'LatestUpdate' and a text column is named 'DeveloperPC'. 2) I made a form named 'frmShutdown' which is opened by startup code as an invisible form. When the app shuts down, the form_closing sub has code which will put the current date/time into the LatestUpdate column IF the name of the PC running the app if = the name as the DeveloperPC - MY development PC. 3) In the AutoUpdater file I wrote (I wrote it in Access - needed a lot of customization so Tony's didn't work), there is a check to compare 'LatestUpdate' dates between the app on the client and the app on the server. If they don't match, and the PC Name <> Client PC name, then the AutoUpdater file will update the app. Otherwise, an update isn't needed. For one of my customers this is important because their connection to their server will be quite slow for the next year or so. With this setup, I can forget all about it. The LatestUpdate field on my PC gets the current date/time every time I close the app, but that only happens on my PC. The comparison happens every time a client opens the app, and the update is triggered automatically if needed. Dan PS - I used to do this using the Last Modified Date, but that's only accurate once a day. Occasionally I needed to update more frequently. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Monday, March 02, 2015 9:46 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Automatic Update Function " Having version details or control values in the tables managed by the app requires the app, or in this case the DBMS to run to check and also to update those values." If you are worried that an application is not capable of reliably storing its version information locally, then why would you trust it to store any data, anywhere? Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of James Button Sent: Friday, February 27, 2015 5:35 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Automatic Update Function I am not saying there is any difficult to surmount problems with having data in local database tables, just that I would prefer to be able to totally replace the front-end facility with the batch copy process. Not so much KISS as Keep It Dead Simple - and avoid anything on the local system that is part of the downloaded app, rather than a conditioner to have that local copy completely replaced. Having version details or control values in the tables managed by the app requires the app, or in this case the DBMS to run to check and also to update those values. JimB -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Friday, February 27, 2015 9:58 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Automatic Update Function " I'd be wary about the process that has the version in a local store" - why? " - and the implications of whatever else is in local stores " - what implications would those be? More correctly, what are you assuming here? Lambert -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of James Button Sent: Friday, February 27, 2015 1:58 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Automatic Update Function I'd be wary about the process that has the version in a local store - and the implications of whatever else is in local stores - I'd prefer to have a check before actually starting the application's environment, and 'fix' the facility before the windows OS begins to start it up. Then again I try to work on the basis that idiot-proof is having to deal with improved models getting even more help from the OS and software facility writers all the time, so they don't need any extra help from me! However - the question is what is in the setup managed by Janet and her associates. JimB -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Friday, February 27, 2015 3:35 PM To: 'Database Advisors' Subject: Re: [AccessD] Automatic Update Function 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 at 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 -- 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 -- 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