Subject | Re: [firebird-support] rdb$db_key and concurrency |
---|---|
Author | Helen Borrie |
Post date | 2004-03-24T23:07:35Z |
At 07:52 PM 24/03/2004 +0000, you wrote:
nothing like what you're proposing. The rdb$db_key provides a physical
disk location for the committed version of a row as seen from *your*
transaction. If someone came along after you started your transaction and
committed a newer version, that newer version would (potentially) have a
different rdb$db_key.
Inside your transaction, your isolation level determines what you can know
about what's "out there". There's only one way to tell whether a record
has changed on the outside and that's to attempt to update or delete
it. If you get a conflict, someone else altered (or is altering) the
row. In Read Committed isolation you can set up to not care about
overwriting...but that's not much use if your purpose is to find out
whether a conflict exists.
/heLen
>Was just reading this webpage:It's safe to use it as Claudio describes. But what Claudio describes is
>
>http://www.cvalde.net/document/mysteriousDbKey.htm
>
>Is it safe to use this field these days (page not been updated since
>2000). Ie for checking in a .net provider dataadapter that a record
>has remained unaltered.
nothing like what you're proposing. The rdb$db_key provides a physical
disk location for the committed version of a row as seen from *your*
transaction. If someone came along after you started your transaction and
committed a newer version, that newer version would (potentially) have a
different rdb$db_key.
Inside your transaction, your isolation level determines what you can know
about what's "out there". There's only one way to tell whether a record
has changed on the outside and that's to attempt to update or delete
it. If you get a conflict, someone else altered (or is altering) the
row. In Read Committed isolation you can set up to not care about
overwriting...but that's not much use if your purpose is to find out
whether a conflict exists.
/heLen