Question

Blast from the past… Got tasked to mange an aging Access 2000 adp used to manage data residing on SQL 2005 server. On one of the dataforms, whenever I try to make a change to a field and save the change back to the database, it times out after about a minute. Increasing the time-out limit only delays the display of the time out error message. I went through all the usual troubleshooting to ensure compatibility (see e.g. this SO question).

This is the setup: a Form is bound to a record set (which is read from the database as a SELECT * FROM table_name query. The result set varies in size depending on filters set on the form, but the result is usually around 200 records (not a lot data…). Some of the fields on the form triggers an automatic save in an associated event handler, which looks something like:

Private Sub EndDate_Exit(Cancel As Integer)
     some checking goes here...
     ...
     DoCmd.RunCommand acCmdSaveRecord
End Sub

Whenver the DoCmd.RunCommand acCmdSaveRecord code is executed, the ADP freezes up until I get a timeout error. Digging into it a little deeper, I looked at the Activity Monitor on the SQL Server. The acCmdSaveRecord triggers an UPDATE statement back to the server to save the changed data. The statement itself is automatically constructed by MS Access based on the underlying table’s primary key, which appears to be defined correctly. However, the update is blocked by a running SELECT statement, which corresponds to the SELECT * FROM table_name query mentioned above.

This leads to a deadlock: The user’s change triggers an UPDATE, which is blocked by a running SELECT (which, as it appears, originated from the Form being edited). How can I get around this?

Things we have tried:

1. We have removed the DoCmd.RunCommand acCmdSaveRecord statement and replaced it with the code Me.Dirty = False, which leads to the exact same behavior as described above.
2. Removed the acCmdSaveRecord complete, and used the built-in Access menu to save the change. This is functionality equivalent to #1, and leads to the exact same behavior.
3. Replace the acCmdSaveRecord call with a stored procedure which saves the change to the specific field. Works great, except that saving the entire record from GUI (save button which calls acCmdSaveRecord) leads to the same deadlock.
4. Reduced the size of the result set associated with the form to a few records. Oddly, still exhibits the EXACT same behavior.

Answer 1

It sounds as though you have set the transaction isolation level to SERIALIZABLE for your connection at some point. See SET TRANSACTION ISOLATION LEVEL (Transact-SQL) for more details. Here is the applicable excerpt (emphasis added):

SERIALIZABLE

Specifies the following:

• Statements cannot read data that has been modified but not yet committed by other transactions.

• No other transactions can modify data that has been read by the current transaction until the current transaction completes.

• Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

Range locks are placed in the range of key values that match the search conditions of each statement executed in a transaction. This blocks other transactions from updating or inserting any rows that would qualify for any of the statements executed by the current transaction. This means that if any of the statements in a transaction are executed a second time, they will read the same set of rows. The range locks are held until the transaction completes. This is the most restrictive of the isolation levels because it locks entire ranges of keys and holds the locks until the transaction completes. Because concurrency is lower, use this option only when necessary. This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.