View Incident Report

Serious

Reported By: Rolf Frei
Reported On: 10/26/2000
For: Version 2.04 Build 1

# 644 Record Locks Not Being Respected with UPDATE SQL Statements

I have added a raise inside the TDataQuery.ExecuteUpdateQuery exception part in DBIsamSq.pas, but I did still not get an lock error if a record is in editmode. In 2.03 any SQL Update on a record which is in editmode I get an Record Lock Error but not anymore in 2.04.

This is a very bad thing as any mastertable can get out of sync with any detail table. If the Keyfield is changed in the mastertable I do a Update on the Detailrecords to reflect the correct new Masterkey value. If now a detailrecord is in editmode the Update SQL works without an error and does update all records correctly, including the record which is in editmode. But as soon the edited
Detailrecord is saved the updated value on tha physical table is overwritten with the old value which was in the record which was in the editmode. Before 2.04 this raised a Record Lock error.

Comments

This error is partly related to the SQL and partly not. The two bugs at work here are:

1) In 2.04 we introduced implicit transactions within the SQL INSERT, UPDATE, and DELETE statements. What is happening is that the record locks are being held due to the transaction, but they are not being isolated properly from one another on a per-table-cursor basis, hence one table cursor will think that's it's already got a lock even though another table cursor actually placed the lock. This only occurs between table cursors on the same physical table, and only when a transaction is in effect.

2) The SQL UPDATE statements were (in general) not properly requesting record locks while executing.

Resolution

Fixed Problem on 10/28/2000 in version 2.05 build 1

More Support Options

Search Incident Reports

Support Forums

Frequently Asked Questions

Technical Bulletins

Technical Articles

Product Manuals

Roadmap