Heenan, Lambert
Lambert.Heenan at aig.com
Mon Mar 2 13:10:15 CST 2015
IMHO the version number information in the front end is not an example of an "[app] apps where there are parts of the data stored locally and other parts stored on a central server". The version number is not part of the data being managed by the application, it is a property of the application, an attribute of it, which is independent of the data the app handles. The version number could be stored in a local text file, as a property of the MS Access accde/accdb file, as an entry in a table in the front end, a registry entry in the local machine, a table entry in another remote location. In short there are any number of ways of keeping track of the application version and none of them have anything to do with the data the application is working with. Just my 2 cents. Lambert :-) -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of James Button Sent: Monday, March 02, 2015 2:00 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Automatic Update Function Dan, No argument with that - My response is re the response: 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?" to my earlier comment " 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." Considering the differences in the processing associated with the various dbms facilities. I have come to be a firm believer in not having apps where there are parts of the data stored locally and other parts stored on a central server. It's OK to have the client systems store data locally while they are active, but any restart of the app should check that the data held locally is as held on the central store. And that there needs to be a robust facility for getting the local parts of an app to be reset. That reset being able to deal with the client PC being restored from a non-contemporaneous set of files. JimB -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters Sent: Monday, March 02, 2015 5:12 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Automatic Update Function Hi Jim, That's not correct. With my AutoUpdater, and with Tony Toew's AutoUpdater, the shortcut on the client PC points to the AutoUpdater file, not the app. So the comparison of last update dates and any updating of the app happens before the app is opened. Dan -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of James Button Sent: Monday, March 02, 2015 11:01 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] Automatic Update Function The point is that it needs the app to be started in order to detect that the app that started is not the version that should have started, and Then it needs that incorrect version of the app to closedown and release the app (and dbms) files and loack so that the new version of the app can be imported. KISS - don't require the app to be started - as in installed and running in order to be able to replace it. Then again, that is my approach, and I accept that my approach is not the only one that can be used. JimB -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Heenan, Lambert Sent: Monday, March 02, 2015 3:46 PM 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 -- 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