|Subject||RE: [firebird-support] Dirty Read|
|Author||Svein Erling Tysvær|
>Hi AllFirebird is not a 'dirty' database and there's no way to update any uncommitted record. Neither is it possible for any other transaction to read changes you've done in your transaction before your transaction commits (so ReadUncommitted does not exist in Firebird). Firebird is not even a database that locks records. Rather, Firebird uses a versioning system, and each record can exist in one or more versions.
>I'm using C# and Firebird Database 2.5 and Firebird Client 2.5.1
>I'm trying to read a specific record that is currently being updated but the same record appears to be locked.
>I cant read it. My code just hangs.
>This is an example code I've put together:-
>FB_Connection AnotherConnection = new FB_Connection(tbDB_Path.Text, Con_DB_Default_DataSource, Con_DB_Default_UserID,
> Con_DB_Default_Password, Con_DB_Default_Port);
>// Start our Transaction
>FtrUpdate = My_FB_Connection.Connection.BeginTransaction (System.Data.IsolationLevel.ReadUncommitted);
>ApplySQL("UPDATE EMPLOYEES_TABLE SET DISPLAY_NAME = 'TOM' WHERE ID = 26", FtrUpdate);
>FdaGeneral = new FbDataAdapter("Select * from EMPLOYEES_TABLE WHERE ID = 26", AnotherConnection.Connection);
>It doesn't matter what type of isolation level I use the specific record seems locked.
>I've used Delphi in the past and had no problems.
>I'm not even explicitly locking the record when updating.
The reason you cannot UPDATE anything, is because another transaction has modified (or deleted or inserted) the record, but not committed yet. Until that transaction commits or rolls back, no other transaction will be able to modify that record (it will be possible to read earlier versions, just not update or delete the record).
So, Firebird does not support dirty reads/updates, but the versioning system makes it so that the only lock conflicts you can get is when two writers tries to update the same record (readers never block anyone and writers never block readers). Your SELECT * FROM EMPLOYEES_TABLE
ought not to fail, but it will return old values at least until FtrUpdate commits (note, I know nothing about C#).