Brett Barabash
BBarabash at TappeConstruction.com
Mon May 3 11:20:21 CDT 2004
Mark,
My batch file shortcuts look identical to any other app shortcut, so I can't
see how it would be perceived as anything different to the end user.
However, if you are unable/unwilling to replace the desktop shortcuts on the
100 machines remotely (login script, network desktop profile, admin c$
access...), then I can see how it would be advantageous to use the current
app's server file as the initial launcher.
At first, I didn't realize that you were planning on using the server db as
the updater/launcher. In this case, my question about checking for a
non-existing database doesn't apply.
So, back to your solution. Following your requirements, here's what I would
do:
- Replace your network db with a simple launcher mdb. This mdb would
contain a single table containing:
- The workstation name (easily extracted using the GetComputerName
API call)
- The current version number for that workstation.
- Include a CURRENTVERSION record in, containing the current version number
of the app database.
- Check the workstation record against the CURRENTVERSION record, and copy
files to the workstation if necessary (see below).
- Launch the application.
Here is some sample code I threw together (You would, of course, have to add
the subs to copy the files and launch the application.):
-----
'Include in module declarations section
Private Declare Function GetComputerName Lib "kernel32" Alias
"GetComputerNameA" _
(ByVal sBuffer As String, lSize As Long) As Long
'Wrapper for GetComputerName API call
Private Function ComputerName() As String
Dim strBuffer As String * 256
Dim lngLen As Long
lngLen = Len(strBuffer)
GetComputerName strBuffer, lngLen
ComputerName = Left$(strBuffer, lngLen)
End Function
'Called from AutoExec
Sub Startup()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strCompName As String
Dim strVersion As Variant
Set db = CurrentDb()
Set rs = db.OpenRecordset("tblVersion", dbOpenDynaset)
rs.FindFirst "ComputerName='CURRENTVERSION'"
strVersion= rs!Version
strCompName = GetComputerName()
rs.FindFirst "ComputerName='" & strCompName & "'"
If rs.NoMatch Then
Call CopyFEFiles
rs.AddNew
rs!ComputerName = strCompName
rs!Version = strVersion
rs.Update
ElseIf rs!Version <> strVersion Then
Call CopyFEFiles
rs.Edit
rs!Version = strVersion
rs.Update
End If
rs.Close
Call LaunchApp
Set rs = Nothing
Set db = Nothing
End Sub
-----
Is this something along the lines of what you were looking for?
-----Original Message-----
From: Mitsules, Mark S. (Newport News) [mailto:Mark.Mitsules at ngc.com]
Sent: Monday, May 03, 2004 10:33 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Deployment Woes
Like I said I'm open for suggestions...the complicated plan was conceived in
order to accommodate ~100 users that have been using their existing desktop
shortcut for a long, long, time. I was thinking that this approach,
although initially a little cumbersome, is still relatively transparent to
the user...in that they still get to click the shortcut to which they are
accustomed.
As for checking the version of a non-existing database? It seems one
approach would be to test for FE existence and proceed, and trap for the
error if it does not exist and begin FE update.
Mark
-----Original Message-----
From: Brett Barabash [mailto:BBarabash at tappeconstruction.com]
Sent: Monday, May 03, 2004 11:17 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Deployment Woes
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.