[AccessD] Deployment Woes

Brett Barabash BBarabash at TappeConstruction.com
Mon May 3 13:06:56 CDT 2004


Mark,
First of all, I don't see a reason why you need to even use batch file.  All
of the file copy operations are already built into VBA, and you can write a
quick 'n' dirty routine to do it from there.

Jürgen's statement doesn't apply in this case, since you already stated that
you want to use the mdb file as the launcher.  In this case, the database is
already open.  The difference between checking for a file and pulling a
record from an update table is of no consequence to the app's performance.

I am still assuming that you don't want to change the user's workstation
paths, which is why I gave you sample code to support this.  If changing
their shortcuts is an option, you could use my batch file approach.  Quick,
simple, easy to maintain, updates are as simple as changing the version
number in the batch file.

I really don't want to start a turf war about the "best" way to do this.  To
each their own.  It just seems that you are confused as to what you are
trying to accomplish, and I'm just trying to nail down the best solution
that will suit your needs.

Again, to recap what I had in mind in my previous message:
- User starts launcher, located at your existing server location.
- Launcher checks workstation record in it's table to determine if it
exists/is up to date.
- If necessary, Launcher copies the newest FE files to workstation, and logs
version number in its own table.
- Launcher shells out to launch FE mdb file stored on workstation, and
closes itself e.g.:

	Shell "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE
c:\myappdir\myapp.mdb"
	Application.Quit

This results in ONE application open at a time (except for split second
between the Shell statement and the Application.Quit statement).


-----Original Message-----
From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com]
Sent: Monday, May 03, 2004 12:41 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Deployment Woes

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


--------------------------------------------------------------------------------------------------------------------
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.




More information about the AccessD mailing list