Ervin Brindza
viner at EUnet.yu
Fri May 20 00:29:05 CDT 2005
Arthur,
take look into my batch file. Your scenario is like mine, except I store the
version number in the file name, so I have a file, e.g. 1811.ver, on the
server.
And the batch file is:
<batch>
@echo off
rem //Change these variables to match file paths and app version
set verfile=1811.ver
set appdir=MyApp\Path
set appfile=MyAppNameFE.mde
set access="c:\Program Files\Microsoft Office\Office\Msaccess.exe"
rem //Check to see if current version is installed
if exist c:\%appdir%\%verfile% goto end
rem //Copy newest application version from server
rem //copy h:\%appdir%\%appfile% c:\%appdir% /y > nul
copy \\medelaserver\server_c\%appdir%\%appfile% c:\%appdir% /y > nul
rem //Delete older .ver files, and create a new one
if exist c:\%appdir%\*.ver del c:\%appdir%\*.ver
type nul > c:\%appdir%\%verfile%
:end
%access% c:\%appdir%\%appfile%
</batch>
HTH,
Ervin
----- Original Message -----
From: "Arthur Fuller" <artful at rogers.com>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Friday, May 20, 2005 4:59 AM
Subject: Re: [AccessD] Front End Updater
> If I understand you correctly (it's late and I've had some vodka), you
> store the version number in a text file rather than the MDB | ADP and
> check it instead. That is interesting, but doesn't it just sidestep the
> question with a smaller file? (Not that that's a bad thing.)
>
> Let me get your scenario straight.
>
> Copies of the app reside on all the local computers.
> One copy of the latest version resides on some server.
> A text file resides on the local computers, and contains the version
> number in standard major/minor form.
> A text file resides on the server, containing the same info but
> presumably with a greater major or minot number.
> A batch file runs, and reads both text files, comparing the numbers. If
> the server number is greater, the batch file copies the server instance
> of the app and the text file to the local computer.
> The batch file then runs the local copy of the app.
>
> I have no objections to this scenario. I just want to know if that's
> precisely what you are saying.
>
> If I am correct, then the working scenario would be something like:
>
> First time, you place the text file and the app on the server, and using
> some technique (could be a simple batch file or something fancier) you
> copy both files to all the workstations.
> Next, you copy a batch file to all workstations. Said batch file
> performs the operations listed above.
> Finally, you place a shortcut on each workstation that points to the
> batch file.
>
> Come update time, you place a new copy of the app and a revised copy of
> the text file on the server.
> User 124 runs her shortcut, invoking the batch file, which uses FIND or
> whatever to compare version numbers.
>
> Do I have the gist?
>
> One issue (it's been a long time since I wrote batch files, but I was
> once pretty good at it). Assuming that you use FIND or something to
> detect the version number in both text files, how do you store them to
> compare them? I'm sure it can be done, I just forget how.
>
> Arthur
>
> Francisco Tapia wrote:
>
> >You are causing an unnecessary load on the network IMHO. for the
> >amount of workstations your app maintains it should not feel sluggish,
> >downloading the app everytime you start it makes you feel that way.
> >There are other factors at play here too. the server that serves up
> >the file can easily be bogged down in connections if someone is making
> >a huge write/read from it, further slowing down your FE start up
> >times... even if it only happens once in a while your user's
> >perception of your program will be that it's slow...
> >
> >A quick check for the version number could solve your issue as well
> >and can be done from the batch file as well, download the .txt w/ the
> >version in it and check it within the batch, if a new version is out,
> >download the new version while prompting the user... otherwise your
> >users just see a snappy app that loads when they double click on it.
> >downloading the entiere FE everytime reguardless of upgrade is a waste
> >of resources... imagine having to wait for IE/FF/Opera to download the
> >program everytime you wanted to browse the web!!!
> >
> >On 5/12/05, John W. Colby <jwcolby at colbyconsulting.com> wrote:
> >
> >
> >>Simplicity. My clients typically have 30-40 stations max, and the FE
takes
> >>a few seconds to load. A batch file took about 3 minutes to cook up and
> >>just works. Obviously if this is going to a system with hundreds of
> >>workstations then something else would be in order. The other thing is
that
> >>by downloading a fresh copy every time they open the FE I can do temp
tables
> >>without worrying about bloat.
> >>
> >>John W. Colby
> >>www.ColbyConsulting.com
> >>
> >>Contribute your unused CPU cycles to a good cause:
> >>http://folding.stanford.edu/
> >>
> >>-----Original Message-----
> >>From: accessd-bounces at databaseadvisors.com
> >>[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Kath Pelletti
> >>Sent: Thursday, May 12, 2005 8:45 PM
> >>To: Access Developers discussion and problem solving
> >>Subject: Re: [AccessD] Front End Updater
> >>
> >>I can't see either why you would want to download the FE every time. I
> >>always do a check on startup and replace only if the version no. has
> >>changed. Kath
> >> ----- Original Message -----
> >> From: Francisco Tapia
> >> To: Access Developers discussion and problem solving
> >> Sent: Friday, May 13, 2005 10:21 AM
> >> Subject: Re: [AccessD] Front End Updater
> >>
> >> That still sucks, the updater I put together checks the ver through
the
> >>day
> >> (about once every hour), a small tiny file less than 1k, that's not a
big
> >> deal but if I was gonna incorporate wan, i'd slow the check to once on
> >>boot
> >> up of the software and once per day (if they never shut down). having
to
> >> dowload whatever the FE size is every time you wanna use the
application
> >> makes it feel clunky.
> >>
> >> On 5/12/05, John W. Colby <jwcolby at colbyconsulting.com> wrote:
> >> >
> >> > On a local lan I just have a batch file that does the download every
> >>time
> >> > the user loads the FE. Over a low speed wan this might be
problematic,
> >> > though over a high speed internet connection it would probably work
just
> >> > fine.
> >> >
> >> > John W. Colby
> >> > www.ColbyConsulting.com <http://www.ColbyConsulting.com>
> >> >
> >> > Contribute your unused CPU cycles to a good cause:
> >> > http://folding.stanford.edu/
> >> >
> >> > -----Original Message-----
> >> > From: accessd-bounces at databaseadvisors.com
> >> > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
> >> > Sent: Thursday, May 12, 2005 2:52 PM
> >> > To: Access Developers discussion and problem solving
> >> > Subject: [AccessD] Front End Updater
> >> >
> >> > I know that this has been kicked around several times in the past,
but
> >> > I'd like to know the current thinking on this subject. Given N users
on
> >> > a LAN (and it might be a WAN), we want to place any updates in one
> >> > standard place (probably using a hardcoded reference to the box and
dir)
> >> > and then have a mechanism that checks to see if the update is more
> >> > recent than the version locally loaded.
> >> >
> >> > What puzzles me about this is: given Access's habit of
re-timestamping
> >> > the ADP/MDB file upon loading, how do you compare versions to see
which
> >> > is more recent? A laptop user, for example, currently disconnected
but
> >> > going to be connected tomorrow morning, may have a more recent
timestamp
> >> > on her file than the one on the net. How do you get around this
problem?
> >> >
> >> > TIA,
> >> > Arthur
> >> >
> >> > >
> >> > >
> >> >
> >> > --
> >> > No virus found in this outgoing message.
> >> > Checked by AVG Anti-Virus.
> >> > Version: 7.0.308 / Virus Database: 266.11.9 - Release Date:
5/12/2005
> >> >
> >> > --
> >> > 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
> >> >
> >>
> >> --
> >> -Francisco
> >> http://pcthis.blogspot.com |PC news with out the jargon!
> >> http://sqlthis.blogspot.com | Tsql and More...
> >> --
> >> 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
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.12 - Release Date: 5/17/2005
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com