Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Record changed or....within a Transaction
Thu, Dec 20 2007 10:59 AMPermanent Link

Norman L. Kleinberg
I think, after reading the manual and scouring this board, that I understand fairly well
the Record changed error and Transactions, including the special "write lock" acquired
during the latter.

My question is: if I am using a pessimistic locking model, start a transaction, put a
table included in the transaction in Edit mode, change data and then Commit the
transaction, should there ever be a circumstance in which I would get the "Record
changed...." error? I don't think so but my application log SEEMS to be indicating I am.
So I just wanted to check here first before I start to debug the situation.  

Thanks for any info.


Norman
Thu, Dec 20 2007 11:44 AMPermanent Link

"Jose Eduardo Helminsky"
Norman

If the process of data updading occurs inside a transaction, you should not
see "Record as changed or deleted by another user" message, since when
database engine starts a transaction it refresh the table buffers and the
table will be locked until you apply Commit or Rollback and therefore no
other user can have access to table to update it.

Eduardo

Thu, Dec 20 2007 11:54 AMPermanent Link

Norman L. Kleinberg
Jose:

See, I learn something every day. I had forgotten about the error occurring even with
pessimistic locking if, when I go to Edit, the record was different than when I first read
it. However, as you pointed out, BeginTransaction does an implicit refresh so that should
not be the problem.

There's something else going on, now to find out what it is.

Thanks for taking the time to post. Pessimistic locking/record changed...... must be
something taught in a graduate course on DBISAM. Smile

Norman

"Jose Eduardo Helminsky" <contato@hpro.com.br> wrote:

Norman

If the process of data updading occurs inside a transaction, you should not
see "Record as changed or deleted by another user" message, since when
database engine starts a transaction it refresh the table buffers and the
table will be locked until you apply Commit or Rollback and therefore no
other user can have access to table to update it.

Eduardo

Thu, Dec 20 2007 12:08 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Norman,

<< My question is: if I am using a pessimistic locking model, start a
transaction, put a table included in the transaction in Edit mode, change
data and then Commit the transaction, should there ever be a circumstance in
which I would get the "Record changed...." error? >>

Sure.  The issue is that the TDataSet-descendant layer (TDBISAMTable,
TDBISAMQuery) buffers records apart from the DBISAM buffering.  The #8708
error is an indication by DBISAM that the record that is being edited via
the TDataSet layer (the buffered record) is different than what DBISAM has
buffered in the engine for that row (which after an edit, is the guaranteed
most recent version of the record).  Starting a transaction refreshes the
buffers in the engine, but not in any attached TDataSet-descendants.  To
refresh them, you have to call the Refresh method after the transaction has
been started.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Dec 20 2007 12:34 PMPermanent Link

Norman L. Kleinberg
Tim:

Ahhhh, so it IS an issue analogous to getting the record changed error with pessimistic
locking when you Edit.
(I was wrong, this stuff is PhD thesis material Smile).

Good stuff. Thanks for taking the time to give me the definitive response.



Norman

---------------------------------------------------------------------------------------------
-snip-

Sure.  The issue is that the TDataSet-descendant layer (TDBISAMTable,
TDBISAMQuery) buffers records apart from the DBISAM buffering.  The #8708
error is an indication by DBISAM that the record that is being edited via
the TDataSet layer (the buffered record) is different than what DBISAM has
buffered in the engine for that row (which after an edit, is the guaranteed
most recent version of the record).  Starting a transaction refreshes the
buffers in the engine, but not in any attached TDataSet-descendants.  To
refresh them, you have to call the Refresh method after the transaction has
been started.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Dec 21 2007 3:39 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Norman,

<< Ahhhh, so it IS an issue analogous to getting the record changed error
with pessimistic locking when you Edit. >>

Yes, you can literally get an 8708 error any time that the underlying data
is different than what has been buffered by the TDataSet layer.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image