Dan Waters
dwaters at usinternet.com
Fri May 20 07:08:30 CDT 2005
Arthur, Take a look at the FE Updater written by Tony Toews. There are no batch files and no version files. Updates are completely automatic, and only happen when needed. Go to http://www.granite.ab.ca/access/autofe.htm. What this updater does is copy the contents of a folder from the server to the client's PC. This folder contains all the files that need to be used by the client. All you do is put a new/replacement file into this folder on the server, then the client will check the folder modification date. If the date is newer, then the contents of the folder on the server are copied to the client. This process fast, easy, and transparent. I've used it for about 4 years with no problems. Dan Waters -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Thursday, May 19, 2005 9:59 PM To: Access Developers discussion and problem solving 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