Note that there are some explanatory texts on larger screens.

plurals
  1. POPage-level locking in Jet 4.0 insert? "Can't update; currently locked" error
    primarykey
    data
    text
    <p>I'm getting this error intermittently before record insert on a subform.</p> <p>The subform is in 'continuous records' mode. The subform recordsource is a parameter query opened via querydef.OpenRecordset, in dbOpenDynaset mode.</p> <p>Using MS Access 2003, Access 2000 file format for front-end and back-end, both FE and BE have record-level locking selected, all forms have "No Locks" for RecordLocks. </p> <p>Googling, it seems many people have had similar situations but no solutions found.</p> <p>Any ideas? It seems like page-level locking is being used instead of record-level, when the insert is done on the form.</p> <ol> <li><p>Could it be that the back-end connection (via DAO OpenDatabase) reverts to page-level locking? Any setting in the DAO connectionstring that could be helpful if so?</p></li> <li><p>Could it be that by opening the recordset via querydef, it uses page-level locking, so that a simultaneous record-update and record-insert (recordset.AddNew or whatever) may conflict? Microsoft's article <a href="http://msdn.microsoft.com/en-us/library/aa189633%28v=office.10%29.aspx" rel="nofollow">here</a> suggests this might be the case (although it's unclear, as OpenRecordset is supposed to be OK):</p></li> </ol> <blockquote> However, any SQL Data Manipulation Language (DML) queries — that is, queries that add, delete, or modify records — that are run from ADO (when you use the Microsoft Jet 4.0 OLE DB Provider), DAO, or the Access query user interface will use page-level locking. Page-level locking is used for SQL DML statements to improve performance when you are working with many records. However, even when record-level locking is turned on, it is not used for updates to values in memo fields and values in fields that are indexed — they still require page-level locking. </blockquote>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI have always worked on the basis of the assertion that DAO uses page-level locking and cannot use record-level locking. Personally, I don't think record-level locking is that big of a deal. Optimistic locking vastly decreases any collisions of edits between users. You seem to be updating a table that you have open in a subform. Is it possible the form is dirty when you attempt the update?
      singulars
    2. COThe outer form isn't bound to any recordset, so the fact that it's a subform is not actually that relevant. The situation where it's happening, I think, is that one user is editing an existing record and another user is attempting enter a new record - it's at the point where the second starts typing in the new record (and it runs the AddRec or whatever). I will try explicitly setting optimistic locking in the OpenRecordset but don't expect this to help since the users are editing different records. I may try instead disabling AllowAdds form property and do it manually with an insert query.
      singulars
    3. COIf the problem is being caused by two actual users, and not by yourself locking the pages with unsaved edits, doing the insert in SQL won't change anything at all. If it's locked, it's locked. I think there's something else going on here, as I've never encountered a page locking issue in production use when under optimistic locking.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload