*.ldb File 4

[sabloomer]

I believe that the *.ldb file contains the users connected to a database and what login they are using. I am finding that the file contains users that are no longer in the database. (One user show three times, but her laptop is off and unplugged.) Is that normal, or does that mean I have something like a VBA recordset that was not closed correctly?

Thank you to anyone that can help me understand this file,

sabloomer

 

[sfreeman]

The ldb file will remain open with info about who has used the db until ALL users haved exited.

Should be nothing to worry about.

Is this creating an issue for you??



Sam_F
"90% of the problem is asking the right question.

 

[sabloomer]

Sam_F,

I have a large database, 400 mb, in a very multi-user environment. I can go weeks without have the database becoming corrupt, and then it can happen twice a day. I am trying to figure out if there is one person or one process that is causing the problem. I use the file to try to tell me who is in the database, but as you said it isn't a snapshot in time, it is a list of all users who have been in or are currently in the database.

Thanks,

sabloomer

 

[Varga]

I'm having a similar problem that I can't find any answers for.

Sabloomer,
When you close the database, is the 'Msaccess.exe' process still running?
(Use "Ctrl+Shift+Esc" to look in the task manager.)

When I close Access my ".ldb" file locks and the process keeps running.

As a test I removed all the code, references, reports, forms, and all but one table table, and this still happens.

Try this:
I created a NEW blank test database, and created a table with 2 rows and 2 columns.
*If I open the database then close it (without doing anything) the programs ends and the process ends too.

*If I open the database and then open the table (in datasheet view) the program will end fine but the process keeps going. If I try to open it again while the process is still running, then the ".ldb" gets created but the program will not open, and the ".ldb" file is locked and can't be deleted.
I have to kill the "Msaccess.exe" process in the task manager, then delete the ".ldb" file, then I can open the database again just fine.

*If I open this database and just open the table in design view, then I can close the database and the process ends normally. I can even open the table in design view, then use the toolbar button to switch to datasheet view, and I can close the program fine and the process ends.

As soon as I open a table, form, report, or anything (not in design view) the process locks and will not go away.

Does this sound like your problem?

Does anyone have any ideas?

I hope this helps.
-Varg

 

[jrbarnett]

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q176670

John

 

[Varga]

jrbarnett,
I started reading the page you referenced.
That might help. I'll have to check it out.
Seeing what is locked and why, should point me to the problem.

One thing, on the page it says "Applies to: Microsoft Access 97 Standard Edition".
I'm running Acess 2000, will it work on 2000?

Please let me know,
Thanks,
-Varg

 

[Varga]

jrbarnett,
I should have mentioned that I'm using Access 2000 on WinXP Pro.
I think I created most of it in Access 97 then converted it to Access 2000 more than a year ago.

The link you refered to is only for Access97 and wont work on a XP machine.
I tried an attached link (in the page you mentioned) "How to determine who is logged on to a database... in Access 2000.
That only tells me that I'm logged on (it's on my C: drive and only I'm using the test DB).

All I have to do is create a blank form (not based on any data) in a blank database and if I open it in form view (or a table, or query) the process locks and wont end when I close Access.
(See above for more details.)
Why would a fairly empty DB lock the process as soon as I open a form or table?
(I'm a worrier, could it be spyware? I run multiple spyware programs, so if it is, they can't detect it.)

The references added by default (on a new DB) are "Visual Basic For Applications", "Microsoft Access 9.0 Object Library", "OLE Automation", and "Microsoft ActiveX Data Objects 2.1 Library".
I can't un-reference the first two, and removing the other tow doesn't solve the problem and causes more issues.

Help?

Is there an Access 2000 version of 'Jetutils.exe' that will run on XP?
I want to see what's locked and why.

Thanks,
-Varg

 

[Varga]

sabloomer,
RE: Seeing who is logged onto your database.
The *.ldb file will show disconnected users until every user logs out and the file disappears, as stated above. (It's supposed to disappear. :-( )
I followed a link above, in this thread, and I found another usefull page,

http://support.microsoft.com/kb/198755/EN-US/

The code provided on this page can be put into your Database and you can run it to see who is currently logged into your DB, or send a messagebox only to logged on users. I tried this code and it works like a dream!!!


jrbarnett, (or anyone)
I use three FREE programs to locate and diagnose computer problems. (and to see what the computer is REALLY doing).

http://www.sysinternals.com/ntw2k/source/filemon.shtml

http://www.sysinternals.com/ntw2k/source/regmon.shtml

http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

SystemInternals has much, much more, but these three do the job.

After I exit Access 2000 the MSACCESS.EXE process keeps running (i.e. stays in memory). The 'File Monitor' program shows me that after I close Access, the MSACCESS.EXE process keeps reading
"C:\Program Files\Common Files\System\SYSTEM.MDW" every 5 seconds.
The SYSTEM.ldb file locks too, and I'm the only one listed in it.

This file (I found out) is related to the Access Workgroup information, but I don't have any workgroups set-up. I believe this is the default file that access creates.
I'm not very informed, when is comes to Workgroups.
Please help.

I still have to kill the MSACCESS.EXE process before I can reopen the Database again, and delete the locked '.ldb' files.

Why would MSACCESS.EXE keep reading the workgroup file, after Access is closed?
Why does it not release the file?

I hope this sheds some light on my problem.
Any ideas?

Please let me know,
Thanks,
-Varg

 

[sabloomer]

Varga,

Thank you for the feeback. I will give it a try. I will let you know what happens when you run that on a database that has gone to a "unrecognized format".

Thanks again,

sabloomer

 

[Varga]

sabloomer,
Is it saying "Unrecognized Format" when you try to open the database? Can you open the DB at all?

You could try importing all your objects into a new database, if it will let you import from a "unrecognized format" DB? To start fresh.

Then try that code to see who's logged on in real time.

Hope this helps.
-Varg ;-)

 

[Hap007]

Dear Varg,

The problem you describe (Access continues to run after exit) is usually caused by an open recordset.

You need to close and release all recordsets that you create, in VBA code, at the end of each sub routine or function. If you fail to do this, then the problem of access not closing may happen.

Regarding the access 'ldb' file
We should all remember that this is a temporary file that Access creates. So if it can be of use, that is a good thing,

but... consider yourself, as a developer, who might create temporary table or variable to complete your tasks. How would you like future developers to rely on the data in these structures.

Bottom line, this is a temp file and it should be treated as such.

Good Luck,
Hap...


Access Developer

http://www.fcs-software.com/fcsaccessdev.html

Access based Add-on Solutions
Access Consultants forum

http://www.tek-tips.com/threadminder.cfm?pid=1121

 

[Varga]

Hap007,
I urge you to re-read this thread.
I've looked all over the net, and that's the standard response, "Close your recordsets".

To test my problem I created a new DB with ONLY a table.
(No VB, no recordsets, no outside references, nothing but a table with two records. Read above, I've been very specific and done lots of testing.) If I open the table in design view, then everything is fine. If I just open the table then the process locks.

What's wrong with the code supplied by microsoft?

http://support.microsoft.com/kb/198755/EN-US/

A ".ldb" file is good but not the best, sabloomer wanted a real time view.
"How would you like future developers to rely on the data in these structures?" -What do you mean?

Please clarify your response,
Thanks,
-Varg ;-)

 

[Hap007]

Dear Varg,

My comment:

"How would you like future developers to rely on the data in these structures?"

What do you mean?

What I was was trying to say is this:

The 'ldb' file is a temporary work space that Microsoft uses to store who-is in the database, what locks may be inplace, and who knows whatelse.

Now, I as a developer will use any means to get as much information (published or not) from any application that I work on, but we must be careful about going backdoor to access that data.

I could be wrong, (probably I am wrong) but relying on temporary structures can be dangerous.

I look as the ldb file as a undocumented switch or feature. I use it knowing the risks, but I am very careful because the behavior could change without notice.

I was just trying to compare using a non-supported feature like someone using a temporary structure in your own program.

For instance:
I might create a temporary variable to pass to a report when the report is run for 1 customer, but when the same report is run for all customers, I may ignore the variable.

Well, say another developer works on my code and sees that I create this temp variable, and they make changes that rely on this temp variable, well things could go wrong with their revisions because the temp variable might be set wrong.

This is a simple example and we all can look at code in access, but what if it were compiled and we did not know what the variable was actually used for.

Bottom line, just be very cautious when using/relying on undocumented features.

Enjoy,
Hap...


Access Developer

http://www.fcs-software.com/fcsaccessdev.html

Access based Add-on Solutions
Access Consultants forum

http://www.tek-tips.com/threadminder.cfm?pid=1121