[AccessD] Deployment Woes

If you choose to determine their current app version by checking for the
existence of a file (e.g. DbName_FE_1.mdb), then yes, you wouldn't need to
keep track of updates in a table in the launcher mdb.  That way or my way,
doesn't really matter, they'll both do the job just fine.

Here's why I said that Jürgen's statement about performance didn't apply:
- He was comparing checking for a file's existence, vs. opening a copy of
the FE mdb to check a database version property.
- I was comparing checking for a file's existence vs. retrieving a record
from a table.

Performance wise, you are looking at no tangible difference if you lookup
the value from a table instead of looking for a file on their hard drive.
(unless you get all bent out of shape about performance differences of < .01
sec).

IMHO, the only valid consideration is choosing the solution that is the
easiest to implement, maintain and deploy.  I'll leave it to you to decide
what works best for you.

Off the top of my head, I would guess that the easiest way to keep someone
from directly opening a FE on the server would be to check the
CurrentProject.Path property at startup (AutoExec).  If it is anything other
than your app directory, kick them out.


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


How do I handle the situation where someone opens the server copy of the FE
directly?


Brett,

There is no doubt that I am confused;)  But here goes...

>> I don't see a reason why you need to even use batch file <<
I agree, I'm re-working it accordingly.

>> Jürgen's statement doesn't apply << -Jürgen...please correct me if I'm
wrong, but I disagree.  For example...the launcher app contains a version
record "2", and the filename of the local FE is "DbName_FE_1.mdb".  Since
Instr(strFileName, strVersion) = 0, I update the FE.  If I use this method I
see no reason to store a table of workstations and the latest installed
FE...or am I missing something?

>> recap <<
Except for the version checking...exactly.

>> ONE application open at a time <<
Excellent...thank you for clarifying this.



Mark


-----Original Message-----
From: Brett Barabash [mailto:BBarabash at tappeconstruction.com] 
Sent: Monday, May 03, 2004 2:07 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Deployment Woes


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

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