Why is my computer name still in the .ldb file?

[Judy Ward]

I have a database that lives on a network share drive and is used by many
people. During the day I will look at the .ldb file to see who is using the
database. I have noticed that many people's computer names remain in the
..ldb file even after they have exited out of the database
correctly--including my own! And if I open the database a second time, my
computer name appears in the .ldb file two times.

I have a form, frmMain, that opens automatically when users open the
database. This form has many list boxes that look up values from tables.
Should I be doing something in the close event of this form to clear out or
close something (and if so, what?)?

I would appreciate any advice or pointers to articles on this subject
because I am stumped!

Thank you,
Judy

 

[Gina Whipp]

Judy,

Okay a few questions here so you can get the proper response...

1. Is the database split?
2. If not, where is is sitting?
3. If yes, where is the back-end?
4. Are the Users sharing the same front end?
5. If not, where are the front ends?
6. What kind of network?
7. Windows version?
8. Access version?
9. If on a network, what persmissions do the Users have/not have?

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

 

[Tony Toews [MVP]]

I have a database that lives on a network share drive and is used by many
people. During the day I will look at the .ldb file to see who is using the
database. I have noticed that many people's computer names remain in the
.ldb file even after they have exited out of the database
correctly--including my own! And if I open the database a second time, my
computer name appears in the .ldb file two times.

This is standard behavior. There are a number of "slots" in the ldb
file. As users start accessing the BE the next available slot is
used. So if there are two users in the database and the first user
exits the first users workstation name and Access user id will remain
in the first slot. Now a third user comes in and grabs the first slot
because it's the first available. Now the first user comes back in
while the other two users and they would get the third slot. When
the first user exits from the third slot then thier work station name
will still exist in the ldb file.

All this keeps happening until the last user exits the ldb and they
have delete privileges on the ldb file or the folder. Whereupon the
ldb file gets deleted.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[Judy Ward]

Thank you for this explanation. I have been wondering about this for quite
some time--and thinking I caused it by my form design/coding.

 

[Dave]

Thank you for this explanation.  I have been wondering about this for quite
some time--and thinking I caused it by my form design/coding.

This is one reason I've started capturing the logged on user's network
login ID and setting a flag in a user table. The simplest method I
found is a function called fosusername that you probably could find in
this forum. However, I know there are a few uninformed users of my
apps that don't exit via the supplied button, and instead use the
application window close button. Now I disable the application close
button, and re-enable on exit since the supplied button is now the
only means of closing. If you elect to do this, pay close attention to
where you enable/disable, as (I believe) an error could leave the
user's version of Access with a disabled application close button. As
a safeguard, I might have a module that can be imported into a new
database on the user's computer that can reset the button.

 

[Tony Toews [MVP]]

This is one reason I've started capturing the logged on user's network
login ID and setting a flag in a user table. The simplest method I
found is a function called fosusername that you probably could find in
this forum. However, I know there are a few uninformed users of my
apps that don't exit via the supplied button, and instead use the
application window close button. Now I disable the application close
button, and re-enable on exit since the supplied button is now the
only means of closing. If you elect to do this, pay close attention to
where you enable/disable, as (I believe) an error could leave the
user's version of Access with a disabled application close button. As
a safeguard, I might have a module that can be imported into a new
database on the user's computer that can reset the button.

I would suggest using a hidden form which is opened on startup. When
it opens write a record to your log table and save the autonumber ID
in an unbound field on the form. In the forms Close event write the
date/time Now() to another field.

And don't disable the apps close button.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/

 

[Rudolf Lamour]

I would suggest using a hidden form which is opened on startup. When
it opens write a record to your log table and save the autonumber ID
in an unbound field on the form. In the forms Close event write the
date/time Now() to another field.

And don't disable the apps close button.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/