Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
Record changed or....within a Transaction |
Thu, Dec 20 2007 10:59 AM | Permanent 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 AM | Permanent 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 AM | Permanent 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. 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 ). 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Thursday, April 18, 2024 at 10:42 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |