Link to home
Start Free TrialLog in
Avatar of PremkumarBalwani
PremkumarBalwani

asked on

Possible Corruption in betrieve .dat extension files (.^01)

i have a 3rd party application that uses pervasive database. One of the files in the database is growing way tooo much with all the data that needs to be in there, and apparently now has 3 extension files.
tableName.^01
tableName.^02
tableName.^03

recently the application started crashing with error I/O 103. I looked it up and it says that the error is data chunk off set error.

i tried to re-index this huge file but i wont let me because of the exentsions. the butil command goes beserk when dealing with extension files and there is no utility out there that would help me re-index this file.

also when the app is loading it shows the following error in the log file...
System Error: 116.12.0 File: FileLocation

The actual database is Pervasive Version 9.11, but all the .dat files are of version 7.0 !! i would want to convert the files to version 9.0 as well but am not sure how to with extension files being involved. could that be the problem as well??

My first guesss is the file is corrupt but is there any way i can bring it back up ?/? any help would be greatly appreciated.....

thanks a lot in advance....
Avatar of Mirtheil
Mirtheil
Flag of United States of America image

>>i tried to re-index this huge file but i wont let me because of the exentsions. the butil command goes beserk when dealing with extension files and there is no utility out there that would help me re-index this file.

What do you mean?  What error were you seeing?  Were you trying to rebuild each extension file individually?   You don't need to do that.

Rebuilding to the V9 format won't necessarily give you any extra prevention from corruption.   To rebuild the files, you should use the Rebuild utility (either the command line or the GUI version).

In regards to the 103 error, how is the file being accessed?  Is it through Btrieve or ODBC/SQL?  If it's ODBC/SQL, the problem may be related to incorrectly defined DDFs.  
Avatar of PremkumarBalwani
PremkumarBalwani

ASKER

Thanx for the quick reply mirtheil.....

i tried to do a rebuild using the gui that comes with Version 9..... and it failed...here is the log info....
/////*************** LOG FILE INFO *******///////////////////////
The rebuild operation start time is 07/25/07 00:24:18.
rbldcli -c -s -f9  C:\noble\ND60\NHWTRX.DAT

REBUILD-20: The utility is processing C:\noble\ND60\NHWTRX.DAT.
REBUILD-68: Status code 2 was returned while copying records from the following file:
C:\noble\ND60\NHWTRX.DAT.
REBUILD rejected a total of 1285637 records.
REBUILD copied a total of 619136 records.
REBUILD rebuilt a total of      0 indexes.
The rebuild operation end time is 07/25/07 00:40:11.
/////////***************LOG INFO ENDS HERE**********************////////////////////

what i meant by butil (re-indexing) the file is, i have a .TAD file which is basic indexed structure of the actual file

i usually back up the actual content of the current file...
file.DAT to file_back.DAT

and then run a copy command to create a clean structure of the table...
copy file.TAD file.DAT

and then run a butil -copy command to load the data into this newly created structure...
butil -copy file_back.DAT file.DAT

when i run that.... it sort of re-indexes the file.. but for the file in question it stops at record # 619136 and then returns a microkernal error # = 2 ....... which is exactly the same as the log file....


Any ideas as to how i can fix this issue???

thanx a lot in advance...
ASKER CERTIFIED SOLUTION
Avatar of Bill Bach
Bill Bach
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
A few other things I noticed when rereading your original post:

1) PSQLv9.1 did have some bugs that caused substantial file growth under certain conditions, specifically apps that rapidly open the file, insert a record or two, and then close the file right away.  Patching to PSQLv9.5 (a.k.a. Service Pack 2) should help alleviate this issue.

2) Do not worry about getting the files to 9.x format just yet -- get the problem file dealt with first.  When done, you'll be able to use the Rebuild tool properly to rebuild the files and upgrade the file format.  When you move to the 8.x or newer format, you will see a performance gain, so it is a good idea to do so.
Is this issue still open, or can we close it?