Mitsules, Mark S. (Newport News)
Mark.Mitsules at ngc.com
Mon May 3 10:02:21 CDT 2004
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 -- ---------------------------------------------------------------------------- ---------------------------------------- The information in this email may contain confidential information that is legally privileged. The information is only for the use of the intended recipient(s) named above. If you are not the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or the taking of any action in regard to the content of this email is strictly prohibited. If transmission is incorrect, unclear, or incomplete, please notify the sender immediately. The authorized recipient(s) of this information is/are prohibited from disclosing this information to any other party and is/are required to destroy the information after its stated need has been fulfilled. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Tappe Construction Co. This footer also confirms that this email message has been scanned for the presence of computer viruses.Scanning of this message and addition of this footer is performed by SurfControl E-mail Filter software in conjunction with virus detection software. -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com