Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 21 total |
Indexes do not match record data and are invalid. |
Wed, Apr 5 2006 1:16 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |