[AccessD] Automatic Update Function

Yes, I have always used the batch file approach too.  The user actually click on the BAT file, which looks like the Database FE, but it check the version in the FE against the version on the server, and if they are different it downloads the current version to their desktop and opens it.

This is all very fast and seamless. The users don't even notice.

Cheers
Darryl.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Tuesday, 3 March 2015 9:38 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Automatic Update Function

Did I miss something?  I thought this was a simple matter of getting the latest FE off the server.  My KISS approach to this is that every time the user starts their app, they really just run a batch file which copies the latest copy of the FE off a location on the server and fires it up.  A two line batch file.

We are now discussing data held out in the local copy of the FE not yet updated back to the BE (data store).  If that is in fact the issue then we have a whole nother ball game..

John W. Colby

On 3/2/2015 5:29 PM, James Button wrote:
> 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
>
>
>

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com