Copy FE of DB when it is already open on the server

I just recently changed my database that I'm running from a monolithic
DB to a split FE/BE. The front end resides on the client machine and
the BE resides on a network drive. I'm experimenting with a utility
developed by Tony Toews to handle the distribution and subsequent
updates of the software. I'm having some trouble with the overall
upgrade process I've implemented, and I'm hoping one of you may have
an idea how to go about fixing it.

The application works great so long as the users follow the
instructions. They click a shortcut, which used to lead to the old
monolithic database, but has since been switched out with a simple
form that explains that the system has been upgraded. The form load
event dumps a shortcut to their desktop (a shortcut made by Tony's
utility) that they then click to get into the newly split (and
upgraded from A97 to A03) application.

The first problem I'm having is that I can't seem to get my upgrade db
to correctly dump the shortcut to the desktop 100% of the time. It
works 9/10 times, but it would appear that some users have a path to
their desktop which is non conforming to the standard. If it fails, it
pops them a message to contact me and I manually send them the
shortcut. I would like this to work 100% of the time, but to do that I
would need some sort of generic path that will always lead to the
current user's desktop rather than trying to infer it based on their
user id.

The second problem is far more serious. Some of the users are a little
more technically savvy, and decide that my shortcut is not good enough
for them. They manually locate the front end of the database on the
network (the master copy that Tony's program copies out to each user)
and use that one to get in. The instant they open that master copy of
the FE, nobody else can use the regular shortcut to open the
application. This is caused (I believe) by the fact that you cannot
copy a file while it is open (at least you can't using FileCopy). One
single person opening the application the wrong way can bring the
whole thing down.

Correcting the problem by educating the users is extremely difficult
as there are just under 700 of them. They get so many e-mails and
other forms of updates that some people wouldn't end up getting the
memo, and it only takes one person to foul it up. What's made it worse
is that once it is locked up like this, the only way to open it at all
(and for them to get their work done) is to open it incorrectly by
opening up the master FE database. They found that out quick and have
been shooting e-mails all over the place letting people in on 'the
secret'.

To correct this issue, I need some way to insure that they absolutely
cannot use the master FE database. However, I can't just make it auto
close, because it still needs to be copied to the client machine. If I
modify it so that it won't open on the network, then it won't open on
their client machine either.

I've been thinking on it, and have come up with a few possible
solutions, but I wonder if any of you might have some better ideas or
comments.

Idea 1) Create a new network folder for the master FE file to exist in
by itself (as apposed to putting it in the same folder with the
backend). Give everybody in the company read only access and give
myself read/write access.

Cons: Would take up to 2 weeks to get all the paper work filled out
and the changes approved (yes, I know that is asinine.) Furthermore,
I'm not sure that it would work as people would still be able to open
it (albeit, only exclusively) and maybe even make some table updates
(?) as the BE is in a folder they would have read/write access to.

Idea 2) write a module that runs on startup to determine if there is
an ldb file in the master FE folder. If there is, attempt to delete
the .ldb file(in case it didn't auto remove itself when the last user
logged in) then close the program. The idea here is that if you log in
properly, you won't create an .ldb file in the master FE folder, but
if you did log in improperly then you will inevitably create an .ldb
file in that directory which then prompts the application to close.

Cons) I'm not really good at writing functions. I know how to copy a
file and how to delete one, but not how to simply check if one exists.
Maybe I can tinker with it and get it to work in a round about way.

Thanks in advance for any advice any of you may provide.

.

Relevant Pages

  • Re: Copy FE of DB when it is already open on the server
    ... They click a shortcut, which used to lead to the old ... network (the master copy that Tony's program copies out to each user) ... by itself (as apposed to putting it in the same folder with the ... an ldb file in the master FE folder. ...
    (comp.databases.ms-access)
  • Re: Lost ability to login to secure database
    ... First I moved the folder my database was in. ... original shortcut that the wizard made for me. ... to login and cannot open any of my secured databases. ...
    (microsoft.public.access.security)
  • Re: Database Deployment
    ... I am not sure what you mean by UNC?The path to the folder ... >> security and having the shortcut on my desktop, ... >> move the database and shortcut to a shared folder on the ... >Put the backend and the mdw on the server. ...
    (microsoft.public.access.security)
  • Re: Useless User-level security wizard
    ... Your C: drive is NOT the C: drive for any user who's sharing your folder. ... I put the shortcut in the folder in my pc and share the folder. ... >>> database on the network here at my work with other users (that is why I ... >>> this security login), but once I share it I get a big problem. ...
    (microsoft.public.access.forms)
  • password glitches in 20003 and 2000
    ... Access created a shortcut on my desktop that I copied to a folder on the ... server where the database resides. ...
    (microsoft.public.access.security)