[AccessD] Automatic Update Function

Gustav Brock gustav at cactus.dk
Tue Mar 3 08:42:51 CST 2015


Hi Janet

That's quite different as it handles download from a remote site which, of course, may take longer than the few seconds from a local network folder.

/gustav

-----Oprindelig meddelelse-----
Fra: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] På vegne af Janet Erbach
Sendt: 3. marts 2015 15:30
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] Automatic Update Function

And synchronistically enough, I found a vbs script online last night that works along the same lines:

http://www.thatlldoit.com/Documents/ProjMgmt_FEUpdate.txt

It uses a placeholder text file to check whether or not the user has the most recent version on their machine and then launches the update if they do not.

It was written and shared by Bill Mosca on thatlldoit.com.  I tested it out it last night, and am going to deploy it today with my app.  It's quite straightforward and even displays a splash screen with an animated gif so the user can see that something is happening.

On Tue, Mar 3, 2015 at 4:12 AM, Gustav Brock <gustav at cactus.dk> wrote:

> 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