Ms. A's ".LDB" file is a bit (Lot?) strange. It's purpose is to identify record (block) locks by user, not actually to show current log in entries to the db. Since MS didn't intend the file to be used as a log in list, they (strangely -but characteristically) chose to not (always) remove log in entries when a user disconnects. 'They' (the Ms folks) simply (but not obviously) mark the entry (as unused), and (usually) assign the next user to the vacated slot. Of course, this marking and reassigning can only occur when the users connect (and more importantly) disconnect from the db in an "orderly" manner. This (obviously?) doesn't occur on CRASHES, so 0 or more User entries will remain in the LDB file wheen the db is closed via a faullt.
Aparently, someone within Ms realized this and they added some process to simply delete the LDB file under certain conditions (e.g. when the db is closed (in the orderly manner, or the USER is the first or only? user). Some other considerations DO apply, but the exact details are not generally available.
More confusion arises when a database is split in any of several ways, as MS A. Creates an "LDB" file for every mdb file which is accessed - even if there is NO data (Records) to lock, so some users may be confused, looking at a ".LDB" file for the FE, while thinking of a BE db which is not open at all. With the notable exception of MDB's being accessed on read only media, the corresponding LDB is created in the same "folder" as the corresponding MDB, so if you have the traditional "Split" db in Ms. A., as soon as you 'touch' the FE, you will create an LDB on your local system and either create another LDB where the BE is located (if you are the FIRST user) or add an entry to the existing LDB for the BE. So, you need to be quite careful of which LDB file you are looking for, and also make sure that all connections to the db are closed, rembering that there are NUMEROUS possabilities in this latter realm.
One approach -which has been discussed in these forums- is to generate a "bootoff" process which uses the LDB file and a simple structure to generate a logoff process (generally implemented to be able to accomplish maintenance). When ever the db gets locked up (or just becomes inactive) have the "bootoff" procedure disconnect all users.
I have NEVER seen the situation where a ".LDB" file cannot be deleted if there are no 'users' connected. This behaviour is not dependent on ANY Ms. A. user characteristic or activity, but is a general property of windows file management, which (very seperatly) tracks 'connections' to each file. If there are NO connections, and you have appropiate permissions, you MAY delete any file, specifically including the ".LDB"s. MichaelRed
m.red@att.net
There is never time to do it right but there is always time to do it over