View Incident Report

Serious

Reported By: Krisztian Kepes
Reported On: 7/25/2014
For: Version 2.17 Build 1

# 4107 Freeing a Query with Manually-Locked Rows Can Result in Dangling Row Locks

We have an app. where the users can save vouchers under transaction. The old code put lock only some tables, but the new put it into the database to avoid side effects of triggers (they can write another tables).

I used a row lock on "scrollparams" table to make a signal. If this signal is on, then the DB is in protected mode, so they couldn't save vouchers. If this row lock don't exists they will save vouchers. It's ok. In the old way the "scrollparams" table was out from the transaction. In the new model (because of DB lock) it is in. When I changed this code I got interesting errors.

The locker code is as follows.

Everything is in transaction!

Ok. It's seems to be ok.
In the first two calls I get ok.
In the third call I got that the row is locked!!! How? I have closed and free the query, so it must release all locks in the database!!!
But it's not!!!

When I put this to the code:

try
if Active then
Cancel;
except
end;

or put this to the code:

try
if Active then
UnlockAllRecords;
except
end;

then I will get good result!

procedure Eppen_Halmozas_Zajlik_E;
var
    Q: TEDBQuery;
begin
    Q := EDB_MakeQuery(nil, 'scroll');
    try
        Add_Halmozo_Rekord_Es_Megnyitas(Q); // PREPARE A QUERY  AND SELECT A SPEC. ROW

        with Q do
        begin

            try
                try
                    Edit; // TRY TO EDIT THE SELECTED ROW
                except
                    raise Exception.Create
                      ('A készlet programban jelenleg éppen halmozás folyik, így a bizonylat rögzítése/módosítása nem lehetséges!');
                end;
            finally

                {
                try
                    if Active then
                        Cancel;
                except
                end;
                }

                {
                try
                    if Active then
                        UnlockAllRecords;
                except
                end;
                }

                try
                    Close;
                    // if Prepared then
                    // UnPrepare;
                except
                end;

            end;
        end;

    finally
        SafeFree(Q); // FREE AND NIL WITH TRY EXCEPT
    end;

end;

Comments and Workarounds

The issue is that EDB wasn't automatically cancelling an edit when the dataset was closed (the implementation was there, but in the wrong location so that it wasn't called correctly). The workaround is to make sure to Cancel any Edits before closing a query.

Resolution

Fixed Problem on 7/30/2014 in version 2.18 build 1

Products Affected

ElevateDB Additional Software and Utilities
ElevateDB DAC Client-Server
ElevateDB DAC Client-Server with Source
ElevateDB DAC Standard
ElevateDB DAC Standard with Source
ElevateDB DAC Trial
ElevateDB LCL Standard with Source
ElevateDB PHP Standard
ElevateDB PHP Standard with Source
ElevateDB PHP Trial
ElevateDB VCL Client-Server
ElevateDB VCL Client-Server with Source
ElevateDB VCL Standard
ElevateDB VCL Standard with Source
ElevateDB VCL Trial

More Support Options

Search Incident Reports

Support Forums

Frequently Asked Questions

Technical Bulletins

Technical Articles

Product Manuals

Roadmap