ldb file

[Jay Kay]

I have a database on a network drive used by several users around the world.
I need to get exclusive use of the database in order to make some changes,
which I can't do as there appears to be others with the database open. The
..ldb file indicates that there are 5 users with the database open, though I
don't know if that's accurate, since it shows my ID in there too and I don't
have the database open at this time. Is there a way that I can I kick out the
other users? (I don't care if they lose data). I can't just ask the users
to get out; with the time differences, some of the users are gone for the day
and won't get the message.

Thanks in advance for your assistance.

 

[Klatuu]

I can't find it at the moment, but I have seed an example mdb for this. The
concept isn't that difficult.

First, you need a one record table in the back end that has a field that
identifies whether the application is open or closed. This you can set
yourself, but now allow users to get at it.

Then in your front end, if you don't already have one, you need a form that
says open for the entire session. Typically, it is hidden. This form should
have a timer event set to check the value of the field in the back end to see
whether the app sould be closed. When the timer fires, check the value of
the field. If it indicates the app should be closed, then give the user a 5
minute warning. Then capture the time in a static variable in the timer
event. When the 5 minutes elapses, quit the application. It would also be a
good idea to check the field when the application starts up to see if the
back end is available, If not, present a message box and quit the app.

 

[Jay Kay]

Thanks for the input. I understand the concept and will look into
implementing that.
However, what I first need is a way to get the users out of the database so
that I can get exclusive use of the database, otherwise I can't make any form
or design changes. Is there a way to kick everyone out?

Thanks

Jay

 

[Klatuu]

No, there is not.
That is what the concept I suggested does.
You shouldn't be working with a production version. You should have a
development version to work on.

 

[Jay Kay]

Ok. Thanks.

No, there is not.
That is what the concept I suggested does.
You shouldn't be working with a production version. You should have a
development version to work on.

 

[Dale Fye]

Your original post and response to Dave's post suggests that you have users
"around the world" using a single Access databasethat sits somewhere on your
network? Can you advise us how they are connecting (Terminal Server), I've
generally found that Access does not work well on a Wide Area Network?

Your first mistake is that you need to separate your application (front end)
from the data (back end). You will still need to implement the solution that
Dave mentions, but by separating your front and back ends, you make it easier
to make changes to the application. Then, all you have to do is push the new
front-end to your users.

Dale

--
Don''t forget to rate the post if it was helpful!

email address is invalid
Please reply to newsgroup only.

 

[Jay Kay]

Unfortunately, this is an example of how a small database which was supposed
to be used just to store a few records has morphed into a "system" that is
supposed to support multi-user access. I'm a bit out of my league regarding
how to separate the front and back ends. Can you point me toward some info
that will provide some details on how to go about this?

Thanks
Jay

 

[JohnC]

For front end deployment maintenance, I've implemented this example:
http://www.databasejournal.com/features/msaccess/article.php/3286111

It works great.

Regarding that .ldb file, perhaps you can give fair warning to your user's
that you are taking the database offline for system maintenance. Then,
during the outage:

a. make a backup!!
b. attempt to delete the .ldb file if it is still there.
c. Take steps to separate your database into front end/back end but for
now, both the front end and back end are located in the same shared folder.
(I'm assuming you are running from a shared folder?)
e. Test
f. Notify user's to begin using the new front end on the shared folder.
g. Begin making revisions to an off-line front end to include code for
front end revision updating on client PCs.
h. Test the updater.
i. Deploy the new front end to client PCs.

John

 

[Tony Toews [MVP]]

Unfortunately, this is an example of how a small database which was supposed
to be used just to store a few records has morphed into a "system" that is
supposed to support multi-user access. I'm a bit out of my league regarding
how to separate the front and back ends. Can you point me toward some info
that will provide some details on how to go about this?

You want to split the MDB into a Front End MDB containing the queries,
forms, reports, macros and modules with just the tables and
relationships in the Back End MDB. The FE is copied to each network
users computer. The FE MDB is linked to the tables in the back end
MDB which resides on a server. You make updates to the FE MDB and
distribute them to the users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at http://www.granite.ab.ca/access/splitapp/ for more info. See the
Auto FE Updater downloads page
http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. The utility also supports Terminal Server/Citrix quite
nicely.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Jay Kay]

Thanks to all for the tips.

You want to split the MDB into a Front End MDB containing the queries,
forms, reports, macros and modules with just the tables and
relationships in the Back End MDB. The FE is copied to each network
users computer. The FE MDB is linked to the tables in the back end
MDB which resides on a server. You make updates to the FE MDB and
distribute them to the users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at http://www.granite.ab.ca/access/splitapp/ for more info. See the
Auto FE Updater downloads page
http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. The utility also supports Terminal Server/Citrix quite
nicely.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Klatuu]

Jay,

Sorry for my delayed response. I have been out of town.
I think you did get some good advice. I did notice nobody pointed out that
there is a wizard that will split the database for you. Tools, Database
Utilities, Database Splitter.