![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 3 of 3 total |
![]() |
Fri, May 25 2007 8:37 AM | Permanent Link |
Michael Shannon | Hello,
I seem to be having a few 8708-related problems with 4.2x. Basically, I am missing (!) the dreaded DBISAM_KEYORRECDELETED "Record has been changed or deleted by another user" error under some circumstances. StrictChangeDetection seemingly has no effect on any of this (it is set to true BTW). Firstly, I am confused as to whether BLOB fields are checked for record "matching" and calculation of the MD5 hash/checksum for a record. At the end of this post (http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=5248&page=1#msg5248) Tim says "The criteria for this is the entire record, i.e. if any part of the record has changed (including BLOBs) then DBISAM will issue this exception." Is this still true or was this only for versions 3.x? This post (http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=50633&page=1#msg50633) and this one (http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=42973&page=1#msg42973) seem to say the same thing: "the RecordHash value does not include BLOBs." My own experiments seem to demonstrate that BLOBs are indeed not included in the hash calculation. If so, I consider this a fairly serious problem: an attempt to edit a BLOB-only-modified (by someone else) record does not throw the 8708 exception, which results in A) inconsistency with non-BLOB editing behavior, B) possible BLOB modifications loss depending on what Memo control is used. Luckily, I do have a workaround (always modify some non-BLOB field in BeforePost), but I just want to confirm that my understanding of the situation is correct. Secondly, it appears that reading a BLOB field's contents results in an automatic implicit record refresh. This post (http://www.elevatesoft.com/scripts/newsgrp. dll?action=openmsg&group=5&msg=23821&page=1#msg23821) says "3.11 has an automatic refresh mechanism in place for BLOBs that to avoid the 8708 error on BLOB reads." This seems to be still in effect. This behavior is also rather problematic (for me) since it exacerbates Memo-only-edits problems where such edits do not produce the 8708 error: an attempt to edit a modified (in any way) record *starting* with a Memo succeeds, and once again, depending on the control used, the Memo may not get refreshed (even if the record has been refreshed). I have a workaround for this one too (avoiding reading BLOBs prior to entering edit mode), but I would like to once again confirm that the above behavior is by design or to be expected. I don't suppose there's an easy way to suppress this auto-refresh (without modifying the source, that is (TDataTable.PerformChangeDetection?)), is there? Or read the BLOB from the record in some way that would bypass the refresh? Thank you, Michael Shannon |
Fri, May 25 2007 2:57 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Michael,
<< I seem to be having a few 8708-related problems with 4.2x. Basically, I am missing (!) the dreaded DBISAM_KEYORRECDELETED "Record has been changed or deleted by another user" error under some circumstances. StrictChangeDetection seemingly has no effect on any of this (it is set to true BTW). >> See here: http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=58694&page=1 << Firstly, I am confused as to whether BLOB fields are checked for record "matching" and calculation of the MD5 hash/checksum for a record. At the end of this post (http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=5248&page=1#msg5248) Tim says "The > criteria for this is the entire record, i.e. if any part of the record has > changed (including BLOBs) then DBISAM will issue this exception." Is this > still true or was this only for versions 3.x? >> 4.x does not fire an 8708 on BLOB changes alone. << My own experiments seem to demonstrate that BLOBs are indeed not included in the hash calculation. If so, I consider this a fairly serious problem: an attempt to edit a BLOB-only-modified (by someone else) record does not throw the 8708 exception, which results in A) inconsistency with non-BLOB editing behavior, B) possible BLOB modifications loss depending on what Memo control is used. Luckily, I do have a workaround (always modify some non-BLOB field in BeforePost), but I just want to confirm that my understanding of the situation is correct. >> Yes, you are correct. Unfortunately it is an architectural issue. It was solved in ElevateDB, but unfortunately is not solvable in DBISAM 4.x without a format change. << Secondly, it appears that reading a BLOB field's contents results in an automatic implicit record refresh. >> It can, in some cases, yes. << I don't suppose there's an easy way to suppress this auto-refresh (without modifying the source, that is (TDataTable.PerformChangeDetection?)), is there? Or read the BLOB from the record in some way that would bypass the refresh? >> It can't bypass the refresh due to the way that the BLOBs work. The offset for the BLB file is stored in the record, therefore if DBISAM finds that the BLOB read fails because the offset is incorrect, it has to refresh the record in order to get the correct BLOB offset. Remember, BLOBs are multi-block structures and are not atomic reads like records are. The record and the BLOB data must be kept in synch by DBISAM. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, May 28 2007 3:52 PM | Permanent Link |
Michael Shannon | Okay, Tim, thank you for the info and confirmation!
Michael Shannon |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |