[AccessD] Automatic Update Function

Gustav Brock gustav at cactus.dk
Tue Mar 3 04:12:52 CST 2015


Hi John

Yes, you missed how to turn an exceptionally simple task (copy file) into a convoluted over-done project.

The added advantage of just copying the frontend before each and every launch is, that support knows that the user always runs a fresh copy. No bloated or corrupted frontends.

I've created a script that the user or supporter initially runs off a network folder. This creates the local folders (in the localappdata store (where the user always has full privileges), copies the file, creates a shortcut on the desktop, and launches the application. 
>From now on, the user will double-click the shortcut which runs the script, recreates folders as needed, copies the frontend, and launches the file. Dead simple at zero cost.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] På vegne af John W. Colby
Sendt: 2. marts 2015 23:38
Til: Access Developers discussion and problem solving
Emne: 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 



More information about the AccessD mailing list