I'm adding a validation check to my program.  In testing the code, I found that a table I have that I know has validation errors seems to pass my check.  I thought perhaps I didn't have table/engine properties set properly for my check, so I tried stepping through the DBSYS source (using Delphi 7), to see if I could compare properties in the utility to properties in my app.  Unfortunately, when I run the compiled utility, the validation check fails.  But the downloaded version of DBSYS matching the source I compiled still reports errors.

Any help in understanding exactly how I have to set up the Table/Engine properties to properly validate/repair a table would be greatly appreciated.

<<
Gordon Turner wrote:
I'm adding a validation check to my program.  In testing the code, I found that a table I have that I know has validation errors seems to pass my check.  I thought perhaps I didn't have table/engine properties set properly for my check, so I tried stepping through the DBSYS source (using Delphi 7), to see if I could compare properties in the utility to properties in my app.  Unfortunately, when I run the compiled utility, the validation check fails.  But the downloaded version of DBSYS matching the source I compiled still reports errors.

Any help in understanding exactly how I have to set up the Table/Engine properties to properly validate/repair a table would be greatly appreciated.
>>

I assume you're referring to verify and repair functionality.

The documentation has a fairly good description:
http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=rsdelphiwin32&version=XE2&topic=Verifying_Repairing_Tables

My code which is very similar to sample has been working for a long time.

What's the DBISAM version of the table and what's the version of your installed components and dbsys ? Just checking as you need to ensure you don't mix and match older/newer versions too much.

Assuming both are running same what verification errors are you seeing (or not seeing in case of your app) ?

Raul

Raul wrote:

I assume you're referring to verify and repair functionality.

The documentation has a fairly good description:
http://www.elevatesoft.com/manual?action=viewtopic&id=dbisam4&product=rsdelphiwin32&version=XE2&topic=Verifying_Repairing_Tables

My code which is very similar to sample has been working for a long time.

What's the DBISAM version of the table and what's the version of your installed components and dbsys ? Just checking as you need to ensure you don't mix and match older/newer versions too much.

Assuming both are running same what verification errors are you seeing (or not seeing in case of your app) ?

Yes, I am referring to verify and repair functionality.  I'm not sure how to tell the specific version of the table (except that it is version 4) but the components and code I tried with was 4.30 Build 2.  (I did have some issues compiling the code - had to substitute the TProgressBar for TGauge).  But executing the Verify returned no errors.  Using version 4.25 Build 7 of the utility I get several "Invalid BLOB Offset into BLOB file for physical record # xxx..." errors.

On 10/21/2013 7:21 PM, Gordon Turner wrote:
> Yes, I am referring to verify and repair functionality.  I'm not sure how to tell the specific version of the table (except that it is version 4) but the components and code I tried with was 4.30 Build 2.  (I did have some issues compiling the code - had to substitute the TProgressBar for TGauge).  But executing the Verify returned no errors.  Using version 4.25 Build 7 of the utility I get several "Invalid BLOB Offset into BLOB file for physical record # xxx..." errors.

Yes, version is for components you use. The reason you're getting errors
is that you're mixing incompatible versions - at this point use 4.30
build 2 only. Do not use 4.25 at all.

There was a change in 4.28 release (it is in release notes):

There is a new design for the BLOB reading/writing that is not
compatible with 4.27 or earlier. Therefore, it is extremely important
that you do not mix DBISAM 4.28 applications with DBISAM 4.27 or earlier
applications. Mixing the two versions can cause improper truncation of
BLOB data, and that includes using a 4.27 application on any data that
has been updated by DBISAM 4.28, even if it is not concurrently. The
issue is that 4.27 and earlier versions recylcle BLOB blocks on a
per-block basis, whereas 4.28 and higher versions recycle BLOB blocks on
a per-row basis.


Raul