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

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

Okay, Tim, thank you for the info and confirmation!

Michael Shannon