Jürgen Welz
jwelz at hotmail.com
Mon May 3 14:29:51 CDT 2004
A launcher can do it all very well. Including making folders, verifying user name and getting itself out of the way. It also gives you access to api functions, for example, I used a copyfile function that allows you to overwrite the destination if it exists. I use a run code macro and have everything in a single tiny module. It does mean that there will momentarily be two access application processes open concurrently for each user. I use the ShellExecute api call to launch the file after a successful copy and when it succeeds, the next line of code is: Application.Quit and the launcher disappears. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com >From: "Mitsules, Mark S. (Newport News)" <Mark.Mitsules at ngc.com> > >Upon further reflection...what are the consequences of my sequence of >events? By that, I mean, how many processes will I have running >concurrently? It seems, at first glance, that I'll have the launcher app, >a >.bat file, AND the local front end open all at once until they close the >local front end. This can't be right...at least I hope it's not. How do I >get around this? > >Can the launcher app handle the verification, updating, and launching of >the >FE and then still close? > > >Jürgen, Brett, > > >> Simply checking for a filename is significantly faster than opening a >Database << -Jürgen > >Vs. > > >> - Check the workstation record against the CURRENTVERSION record, and >copy >files to the workstation if necessary (see below). << -Brett > > >I think I'll try the filename method. > > >Mark > > >-----Original Message----- >From: Jürgen Welz [mailto:jwelz at hotmail.com] >Sent: Monday, May 03, 2004 12:29 PM >To: accessd at databaseadvisors.com >Subject: RE: [AccessD] Deployment Woes > > >In the bad old days my former employer had serious security restrictions >that prevented running any number of different kinds of files including >batch files. No user could create a shortcut so I had to make to with the >one that was given to all users. Unfortunately I needed the shortcut to >run > >each users own FE version of the file, especially as they moved to Terminal >Server and I had Word automation issues with multiple users running the >same > >FE. My solution was to convert the mde file that the shortcut pointed at >to > >a file that determined the logged in user, used that information in the >file > >path to that user's unique FE, check a custom database property named >"UserVersion" which was a number from 0 to 9, compare that property with >the > >master FE filename (which had a single digit suffix in the name). If the >property matched the suffix, it launched the FE, otherwise it copied over >the new version and launched it. > >Deployment required a few simple steps: > >1. Make changes to a development file; >2. Update the version property of that file; >3. Set the file suffix; >4. Copy the file to the deployment location; >5. Delete the previous file. > >This approach only copies new versions when they are available. Using a >file name suffix means that it is not necessary to actually open the file >to > >check the version and it might have been more efficient to simply do the >same for checking the existing FE rather than opening a database object to >check the UserVersion property I created. > >I have used schemes based on checking the file creation date with an API >call for the date but found that simply changing a version number from 0 to >9 and back to 0 kept it very simple. You can simply start the version >number from 0 as the test is for version match and not highest version >number. Now that I look at it years later, the only reason for using a >user > >version property rather than a file name was because the users might change >the file name extension manually and because users commonly copied the FE >to > >laptops and this obviated the need to change the name of the coped file. >Simply checking for a filename is significantly faster than opening a >database and checking a version property and some day I may just change it >to do that only. > >BTW, the system automatically creates the folders if they don't exist and >copies over a file if it didn't exist as well. New users are autmatically >accomodated. > > >Ciao >Jürgen Welz >Edmonton, Alberta >jwelz at hotmail.com > > > > > > >From: Brett Barabash <BBarabash at tappeconstruction.com> > > > >Well, I was thinking more like: > > > >1. Split the db. > >2. Move FE material to new FE db. > > > >Utilize batch file (as shown in my example) to: > >3. Check .ver file in user's app directory against current version > >4. Copy down the new FE and supporting files. > >5. Launch the new FE. > > > >Why are you following such a complicated plan? > >Won't it be a huge juggling act to kick them out of the app they just > >logged > >on to to copy down a new FE, and then log them back in again? > >What about users that don't have the FE or app directory on their > >workstation yet? How can they launch it to check the current version if >it > >doesn't exist on their C: drive? > > > >I know there are others who do it this way. For the life of me, I can't > >understand why. <sarcasm>Maybe someone can enlighten me.</sarcasm> > > > > > >-----Original Message----- > >From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com] > >Sent: Monday, May 03, 2004 10:02 AM > >To: 'Access Developers discussion and problem solving' > >Subject: RE: [AccessD] Deployment Woes > > > > > >Brett, Jim, Gustav, > > > >This is the first application that I've really had to tweak to be > >"enterprise" ready. Most all of my previous apps were "low usage"...more > >office automation or strictly robust reporting tools...no real >concurrency > >issues. This application has grown to include multiple data entry >persons > >as well as simultaneous users. I'm open for any suggestions regarding >best > >practices. > > > >So, to combine the suggestions thus far, here is the current plan... > > > >1. Split the db. > >2. Move FE material to new FE db. > >3. Create a version table in new FE db. > >4. Create a version table in the launcher app db. > > > >Utilize existing db as a launcher app that: > >5. Logs in user. > >6. Verifies current version. > >7. Calls a .bat file which, if needed: > >8. Creates the new directory structure for the local FE. > >9. Copies down the new FE and supporting files. > >10. Launches the new FE. > > > >Did I miss anything? Should I try something else? > > > > > >Mark > > > > > >-----Original Message----- > >From: Brett Barabash [mailto:BBarabash at tappeconstruction.com] > >Sent: Friday, April 30, 2004 5:14 PM > >To: 'Access Developers discussion and problem solving' > >Subject: RE: [AccessD] Deployment Woes > > > > > >Mark, > >I do that for all of my distributed apps. > >Adds half a second to the startup time of an application (unless, of > >course, > >it has to copy a new version of the FE to their workstation.) > >Don't know how using a batch file would add to the overhead. Can you > >elaborate? > > > >Oh yeah, here is a sample of my batch file. > >- In our office, all users have the Access 2000 runtime installed on >their > >machines, and we use server-based start menu profiles. > >- Installing new apps on their workstation is as simple as dropping a > >shortcut to the batch file in their start menu directory. > >- I created an app shortcut called Launcher, that has the command line to > >start the app. It is located in the same server directory as the batch > >file, and is executed at the end of the batch file processing. > > > >Well, here it is! > >---------- > >@echo off > >rem ** Change this variable with each new version release > >set verfile=123.ver > > > >rem ** Create directory if necessary > >if exist c:\myappdir\nul goto app > >mkdir c:\myappdir > > > >:app > >rem ** Copy the newest application file from server if it is newer >version > >if exist c:\myappdir\%verfile% goto end > >echo Updating application files. Please Wait... > >copy h:\myappdir\myfrontend.mdb c:\myappdir /y > nul > > > >rem ** Delete the existing version file, and create a new one > >if exist c:\myappdir\*.ver del c:\myappdir\*.ver > >type nul > c:\myappdir\%verfile% > > > >:end > >rem ** Run the application using Access Runtime > >start Launcher > >---------- > > > >-----Original Message----- > >From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com] > >Sent: Friday, April 30, 2004 3:48 PM > >To: '[AccessD]' > >Subject: [AccessD] Deployment Woes > > > > > >I need the weekend to think this over, but I'm open for suggestions. Our > >department currently utilizes an existing database which is not split. > >There are an estimated 100 shortcuts to this database littered throughout > >the department. Do to a rising concern in "concurrency issues", I need >to > >split this db. With such an ingrained dependency on the existing >shortcut, > >it was suggested that I utilize the existing db as nothing more than a > >glorified .bat file starter to distribute the new FE and subsequently >check > >revision status. This seems like an awful lot of overhead in order to > >placate the existing user base, and obviously would increase start-up > >times. > >What do you think? > > > > > > > >Mark _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines