Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 21 total
Thread Indexes do not match record data and are invalid.
Wed, Apr 5 2006 1:16 AMPermanent Link

Dave M
In searching for a bug involving a query (which I wrote),
I decided to run the Database System Utility.

In so doing it revealed an unrelated problem in another file:
"Indexes do not match record data and are invalid".

This was 4.22 build 6 (I think) Client Server, not customized.
I don't have a copy of the index before repair.

The computer has a UPS.
I have to find out if it was turned off during pgm execution, but it probably wasn't.
There is a tray icon for the server. My guess is it was not "tampered with."

Any ideas? Index errors are unsettling.

Dave M
Wed, Apr 5 2006 3:17 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Dave


Are you using threads in the app. If you are doing, and not isolating them properly then index errors can happen. The other area to look at would be customised handlers for full text indexing.

Roy Lambert
Wed, Apr 5 2006 7:50 AMPermanent Link

Dave M
Roy Lambert <roy.lambert@skynet.co.uk> wrote:

Are you using threads in the app...The other area to look at would be customised handlers
for full text indexing.
----------------------------------------------------------------------------------

Your input is appreciated.
But no, neither of the things you mentioned are being employed.


Dave
Wed, Apr 5 2006 8:49 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Dave


OK how about someone did a restore of the .dat but not the .idx?

Roy Lambert
Wed, Apr 5 2006 8:51 AMPermanent Link

Dave M
Roy Lambert <roy.lambert@skynet.co.uk> wrote:

Dave


OK how about someone did a restore of the .dat but not the .idx?
--------------------------------------------------------------------------------

Good idea, but no.

Dave

Wed, Apr 5 2006 2:55 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Dave,

<< In searching for a bug involving a query (which I wrote), I decided to
run the Database System Utility.

In so doing it revealed an unrelated problem in another file: "Indexes do
not match record data and are invalid".

This was 4.22 build 6 (I think) Client Server, not customized. I don't have
a copy of the index before repair.

The computer has a UPS.
I have to find out if it was turned off during pgm execution, but it
probably wasn't.
There is a tray icon for the server. My guess is it was not "tampered
with."

Any ideas? Index errors are unsettling. >>

It could be one of the prior versions of DBISAM that had corruption issues
with indexes:

http://www.elevatesoft.com/scripts/incident.dll?action=search

Search for the word "corrupt".  It's possible that the corruption has been
there for some time.

Also, check the event log for the OS and see if the machine was restarted in
an improper manner at any time.  Finally, are you running any other
applications that are concurrently accessing the same database as the
database server (such as web apps, etc.) ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Apr 5 2006 6:50 PMPermanent Link

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

It could be one of the prior versions of DBISAM that had corruption issues
with indexes:

Also, check the event log for the OS and see if the machine was restarted in
an improper manner at any time.  Finally, are you running any other
applications that are concurrently accessing the same database as the
database server (such as web apps, etc.) ?
------------------------------------------------------------------------------------

There are no unusual events recorded by XP. Other apps, yes, FireFox or IE sometimes, and
Remote Assistance.

More problems.

Upgraded from 4.22b6 to 4.23b2.
Examined same data file (using 4.23b) that was reported corrupt last night at 10:30 by
4.22b. Guess what, the file had a time stamp of about 15 minutes later and had more
serious corruption (4.22b).

"Checksum for physical record # XXX (logical record ID of XXX) is invalid and the data is
most likely corrupted..."  (Times 173.)

(I restored from the 10:30 repaired copy, which was OK.) It had corrupted a 2nd time while
I was examining it via windows remote assistance. The 2nd corruption involved about 173
records where the **last field of a compound index key was blank**. Records with non blank
keys were OK.

I guess it's a little "strange", but there are two indexes on the same 5 varchar fields,
91 chars long total. This was a quick fix for incremental searching of addresses, by
padding or trimming the last field. There are no descending fields. One index has full
compression. The index with the padded last field has duplicate byte compression.


Dave M

Thu, Apr 6 2006 4:37 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Dave,

<< Examined same data file (using 4.23b) that was reported corrupt last
night at 10:30 by 4.22b. Guess what, the file had a time stamp of about 15
minutes later and had more serious corruption (4.22b). >>

What do you mean by "examined" ?  Do you mean that you ran a VerifyTable on
the table in question ?

<< "Checksum for physical record # XXX (logical record ID of XXX) is invalid
and the data is most likely corrupted..."  (Times 173.) >>

This was from a prior version of 4.x:

http://www.elevatesoft.com/scripts/incident.dll?action=viewrep&release=4.07&type=f&incident=1744

<< (I restored from the 10:30 repaired copy, which was OK.) It had corrupted
a 2nd time while I was examining it via windows remote assistance. The 2nd
corruption involved about 173 records where the **last field of a compound
index key was blank**. Records with non blank keys were OK. >>

Did DBISAM report the table as corrupted or are you saying that it looked
corrupted ?

Also, you didn't answer this question:

"Finally, are you running any other applications that are concurrently
accessing the same database as the database server (such as web apps, etc.)
?"

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Apr 7 2006 1:40 AMPermanent Link

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

> What do you mean by "examined" ?  Do you mean that you ran a VerifyTable on
> the table in question ?

Ran Verify table DataBase System Utility included with 4.23b2 on table repaired by
DataBase System Utility 4.22b6.  

>> This was from a prior version of 4.x:
>>
http://www.elevatesoft.com/scripts/incident.dll?action=viewrep&release=4.07&type=f&incident=1744

Interesting read. Sounds like the same thing. Be advised though, that this table was never
4.07.
As I recall, it started as 4.22b6.

>Did DBISAM report the table as corrupted or are you saying that it looked
>corrupted ?

As above, Table verified by Database system utility.  

>Also, you didn't answer this question:
>"Finally, are you running any other applications that are concurrently
>accessing the same database as the database server (such as web apps, etc.)
>?"

Sorry, I was awake for 2 days, which apparently rendered me almost incapable of reading
and answering questions....
No other apps accessing. HOWEVER, eTrust (ez Armor) antivirus usually is running, but not
last nite when 2nd incident happened.

After more examination (using TDBISAMTables), it appears only a few fields were changed by
the user.  
*NO CORRUPTION IN THE FIELDS.*  However, I only checked the fields that normally show up
in dbsys.

This is also strange.  I ran Database system utility today on my copy of the "bad file."
It says it is ok. I am going to obtain another copy of the file that was reported to have
corruption and see
what happens.

Dave M


Fri, Apr 7 2006 5:27 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Dave,

<< Interesting read. Sounds like the same thing. Be advised though, that
this table was never 4.07.  As I recall, it started as 4.22b6. >>

Frankly, I don't think that is possible.  Later versions didn't have the
problem.

<< Sorry, I was awake for 2 days, which apparently rendered me almost
incapable of reading and answering questions....  No other apps accessing.
HOWEVER, eTrust (ez Armor) antivirus usually is running, but not last nite
when 2nd incident happened. >>

No problem.  I just wanted to make sure that I covered that base.  Mixing up
the LargeFileSupport settings between applications that access the same
database can cause problems, for example.

<< After more examination (using TDBISAMTables), it appears only a few
fields were changed by the user.   *NO CORRUPTION IN THE FIELDS.*  However,
I only checked the fields that normally show up in dbsys. >>

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

<< This is also strange.  I ran Database system utility today on my copy of
the "bad file." It says it is ok. I am going to obtain another copy of the
file that was reported to have corruption and see what happens. >>

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.

--
Tim Young
Elevate Software
www.elevatesoft.com

Page 1 of 3Next Page »
Jump to Page:  1 2 3
Image