Microsoft Access Record-Locking Information

det er en postlås fil

ldb filen indeholder låseinformation - dvs. når du læser eller opdaterer en række sættes der en lås på rækken så databasen kan sikre at ikke andre foretager opdateringer imens.

Indeholder den ikke bare informationer om hvem der har haft databasen åben? Hvis man åbner filen i Notebook, så ser man ingen informationer om records eller ligt. Kun bruger- og maskinenavn!?

Kan dette give problemmer på et website med mange besøgende?

Jeg har talt med nogen der har problemmer med deres forum, som siger, at hvis de sletter den online så fungerer deres Forum igen. Jeg har aldrig bare selv haft problemmer med den, så jeg synes det er mærkeligt.
Hvad sker der hvis man sletter den?
Og kan den være skyld I at ders forum ikke virker?

The mysterious .LDB file

Everyone has seen the famous .LDB that accompanies an Access MDB. Normally this file is absent, and only appears as soon as a user requests data from the .MDB file. As a user opens
a form or report linked to the back-end database, his copy of Jet creates the .LDB file, and makes entries in the LDB notifying other copies of Jet of the user's activities.

The .LDB file includes information about the user, his computer name, and the records the user has open. As other users open the back-end MDB, their copies of Jet consult the .LDB file to determine which records are being edited.

By the way: The user's name stored in the .LDB file is his Access user name, not their network login name. This means if you don't have security applied to your application, all users have the same name (admin) and some of the multi-user issues described in this article don't apply. It also explains why you may never have had lock contention problems until after you implemented security in your applications.

As a user quits the application, his copy of Jet removes his entries as the application shuts down.

The alternative to using the .LDB file is to record user activity within the back-end .MDB file. Because of the inevitable bloating and contention issues that would occur, Microsoft wisely chose the LDB architecture instead.

Types of locks

Access supports three types of locks: optimistic, pessimistic, and table locks. Without going into a lot of details, these locks can be described as:

Optimistic: The record is locked only at the instant data is written to disk. This type of locking is called optimistic because you seldom expect to see bad things happen from multi-user interaction.

Pessimistic: The record is locked from the moment the user begins editing data until the record's changes are committed. This lock is called pessimistic because it would be a bad thing if users constantly overwrote each other's work.

Table locks: All records in the table are locked.

Optimistic locking is the most common type of lock applied in business applications. Optimistic is most often applied where updates to existing records are carefully controlled or rarely done, such as a phone bill. Two users can simultaneously edit records in the same table, as long as they're not working on the same record. Problems arise only when two users edit the same record at the same time.

Pessimistic is more appropriate in environments where changes to existing records are frequent, and the chance that two users are simultaneously writing to the same record are high (for example, hotel reservations). When you apply a pessimistic lock, anyone else trying to edit a record that exists on the same page (see the next section of this article) is locked out.

Table locking is applicable when you have to perform bulk changes, such as updating all the area codes in a phone numbers table. No other user can add or modify records while a table lock is applied. In fact, no other user can apply any kind of lock (optimistic, pessimistic, or table) while a table lock is in effect.

This article is an excerpt from Mike Groh's "Multi-User Access Secrets" in Access-VB-SQL Advisor magazine. Pro-level subscribers can read the article online at http://Advisor.com/doc/09666.