Tim

I have received some users complains about this kind of error too. A
"simple" repair fix it but they are running DBISAM C/S and I am pretty sure
that there are no other server softwares running and the server didn't crash
since one or two months. I realize this error happens with tables with a lot
of updates and a lot of concurrencies. I have an application log to hold all
the users actions and from two weeks for now I have received two or three
complains about this error.

I am using Delphi6 with DBISAM 4.22 build 6, running in C/S mode and a big
server with 2 Xeon, 2 SCSI mirrored HDs, 2 Gb Ram and *only* running Win2003
Standard Edition + DBISAM, user authentication happens on another server.

Unfortunatelly, it is randomic but it concerns a lot because there are very
big tables with almost 700Mb and it takes around 1:30h to reindex and you
know users, company stops waiting for this.

Eduardo

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

>Sorry, but what do you mean by "fields that normally show up in DBSYS" ?
>They should all show up in DBSYS.

"Normally show up" means user defined fields, not RecordID and RecordHash, which don't
show up when viewing the structure in DBSYS.
All user defined fields were checked for errors. I thought of using GetCurrentRecord to
(if possible) check the entire record, but didn't.
Also, I am a little fuzzy about the record structure.  I assume it starts with RecordID,
then RecordHash, then user fields, then a sometimes a pad. Correct?

>>Did you get both the .DAT and .IDX portions of the table ?  If not (you only
>>have the .dat portion), and the indexes were corrupted, then it would
>>probably pass the repair without reporting any problems.  DBISAM will
>>automatically recreate an empty .IDX with only a pre-defined primary index
>>on the RecordID field if the .IDX is missing.

No, it was a mistake on my part (made while very tired). I apparently misfiled things and
used a copy of the table that was corrected after the first error. Today I got a copy of
the table after the second error.  It does NOT verify using DBSYS. Got 170+ of this type
of error:

Checksum for physical record # 16206 (logical record ID of 16209) is invalid and the data
is most likely corrupted...

Dave M

Dave,

<< All user defined fields were checked for errors. I thought of using
GetCurrentRecord to (if possible) check the entire record, but didn't.
Also, I am a little fuzzy about the record structure.  I assume it starts
with RecordID, then RecordHash, then user fields, then a sometimes a pad.
Correct? >>

The RepairTable checks all system fields for integrity, so there is no need
for you to do so.

<< No, it was a mistake on my part (made while very tired). I apparently
misfiled things and used a copy of the table that was corrected after the
first error. Today I got a copy of the table after the second error.  It
does NOT verify using DBSYS. Got 170+ of this type of error:

Checksum for physical record # 16206 (logical record ID of 16209) is
invalid and the data is most likely corrupted... >>

That's definitely the issue that I linked to before.  Are you sure that this
table was never touched by that prior version (4.07 or earlier) ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Eduardo,

<< I have received some users complains about this kind of error too. A
"simple" repair fix it but they are running DBISAM C/S and I am pretty sure
that there are no other server softwares running and the server didn't crash
since one or two months. I realize this error happens with tables with a lot
of updates and a lot of concurrencies. I have an application log to hold all
the users actions and from two weeks for now I have received two or three
complains about this error. >>

And the database server is the *only* software accessing the database tables
?  You're positive about this ?  The only report that we've had regarding
index corruption since 4.21 that didn't involve a power-down, reset, etc.
has been from a customer that was mixing a LargeFileSupport=True application
with a LargeFileSupport=False application on the same database.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Dave,

>>Checksum for physical record # 16206 (logical record ID of 16209) is
>>invalid and the data is most likely corrupted...

>That's definitely the issue that I linked to before.  Are you sure that this
>table was never touched by that prior version (4.07 or earlier) ?

The data was imported from the BDE (dbase files) using 4.22. As far as I know, I never
*had* 4.07. DBISAM was purchased Dec. 30, 2005. I think the current version then was
4.22b4? Furthermore, all compiles were done using BDS2006. (Was 4.07 BDS2006 ready??)

According to my info, the table started with 4.22b6, following an upgrade from 4.22b.
However, the user did have b4 on the system for a few weeks.

Dave M

Tim

> And the database server is the *only* software accessing the database
> tables ?  You're positive about this ?  The only report that we've had
> regarding index corruption since 4.21 that didn't involve a power-down,
> reset, etc. has been from a customer that was mixing a
> LargeFileSupport=True application with a LargeFileSupport=False
> application on the same database.


BTW, it's very rare. But I am sure about it. I am not using
LargeFileSupport.
It happens with two of my customers that are using Terminal Server. I will
tell you if it happen again.

Eduardo

Eduardo,

<<  It happens with two of my customers that are using Terminal Server. I
will tell you if it happen again. >>

Are the clients running on terminal server and the database server on a
different machine ?  Also, the clients are using remote sessions and C/S
access as opposed to direct access, correct ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Dave,

<< The data was imported from the BDE (dbase files) using 4.22. As far as I
know, I never *had* 4.07. DBISAM was purchased Dec. 30, 2005. I think the
current version then was 4.22b4? Furthermore, all compiles were done using
BDS2006. (Was 4.07 BDS2006 ready??)

According to my info, the table started with 4.22b6, following an upgrade
from 4.22b. However, the user did have b4 on the system for a few weeks. >>

If that's the case, then the repair messages are valid and not from that
DBISAM problem, which means that the table was actually seriously corrupted.
The only thing that would cause that type of data corruption would be an
improper shutdown.  That's the only thing that causes that type of
corruption.

--
Tim Young
Elevate Software
www.elevatesoft.com

>"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

>If that's the case, then the repair messages are valid and not from that
>DBISAM problem, which means that the table was actually seriously corrupted.
>The only thing that would cause that type of data corruption would be an
>improper shutdown.  That's the only thing that causes that type of
>corruption.

I do not recall an improper shutdown of the computer. For about 15 minutes, I was using
the tables (DBISAM C/S) either via my pgm or DBSYS, via XP Remote Assistance. The tables
had just been verified minutes 15 minutes before. The user data was not corrupted.

Dave M

Tim

> Are the clients running on terminal server and the database server on a
> different machine ?  Also, the clients are using remote sessions and C/S
> access as opposed to direct access, correct ?

Yes and Yes. Server 1 is a DBISAM server and Server 2 is for a remote access
and every access to the database are made using remote sessions.

Eduardo