James Button
jamesbutton at blueyonder.co.uk
Mon Mar 2 16:29:39 CST 2015
While still believing that the app version should be checked as a preamble to the app startup, and a trigger for a refresh download. Rather than downloading one of a series of prebuilt sets of local client control data, as part of that download, a rebuild of the client store - perhaps a view (or set of them) would probably be the approach to assemble the individual client sets of data when the app is updated, or reset. Then: When the app starts-up it should check that it has a valid copy of the data held on the central store. Checking of the control data against the server source could be done by validation against a timestamp put into that client systems 'view' as the extract and download was initiated. That should be a reasonably secure means of ensuring that the local client data matches the central store, and is acceptable to the currently installed version of the app. Hopefully, all the local data will be in a single db file, so it should not be possible to have a local system restore, or filecopy part update or revert the data. ---- Accepting that the facility must be running on a local copy of a database puts a different aspect on your processing. Accepting it will be less safe, in that you have difficulty ensuring that data updates from the client systems are all incorporated into the central source. A major problem being that a refresh of the app and it's local database would clear out any detail of data updates that have not been transmitted ( well accepted by the central store as received). I cannot see any easy way to ensure that - with a local system restore, it will be possible to ensure that the central store holds all the data that has been entered at the local system. JimB -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Janet Erbach Sent: Monday, March 02, 2015 4:52 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Automatic Update Function Once again, I thank all of you for your suggestions. I really like the idea about downloading a new version every time the user opens the app - that's so clean and straightforward. I also really, really like the idea of Tony's Auto Updater - but I know they'll never pony up for that. I realize after reading through the thread that I shouldn't implement a new FE update procedure until I take care of a major design change. I need to make a second (and local) backend for the app and populate it with the local data that is specific to each user's production machine configuration. The app uses local tables all day long because of WIFI interruptions, and right now when the app updates it pulls whatever local data is in the server front-end copy and then has to re-create new local tables that are pertinent to the work area. Man, this has been a learning experience for me, and my hind sight vision is better than ever...<sigh>. On Mon, Mar 2, 2015 at 10:14 AM, Dan Waters <df.waters at outlook.com> wrote: > 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 > > -- > 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