Problem 1 : Getting error "Corrupt file - other than header." when opening or scrolling a table.
Problem 2: Getting error "BTree record number mismatch from block <> record <> to block<>." when running TableRepair - Verify.
Versions: All
Cause:
Table is corrupt.
Possible cause by: "Michel Claveau/Hamster" < EnleverXXX.Spam.XXXmcATNo.Spam.mclaveauPointCOM >
Date: May 2004
Adding data to a table with a secondary index, through interactive Table-Add, ObjectPAL table.add() and tcursor,add(), a QBE insert query, or a
SQL Insert statement
Solution:
To avoid the problem: Use tcursors to insert record by record.
To fix the table: Run ObjectPAL compact() method, or restructure the table with Pack table checked.
Comments by: "Steven Green" < greensATdiamondsg.com >
Certain combinations of fields in the key and/or secondary index, and once you pass a certain number of records.. KABOOM!
There is no rule as to what these combinations and number of records will be. But it's been documented a few times over the past few years.
Everyone can reproduce the *exact* same table structure, number of records, etc.. but nobody has been able to create a rule that will predict *why*
it happens in that particular combination..
Comments by: Steve Cooper
Date: 1998
I have paradox 7 installed with service pack 4 & BDE 4.51. Table repair in Paradox 8 reports the file as being good. Pdox 7 reports a Btree error
between 2 different blocks. In 7, once you have completed a verify & rebuild, it still reports as bad. Meanwhile, Paradox 8 works!
Comments by: Ron Hirsch
Date: 7 August 1997
The fields being indexed were floating point numbers (N) because this database was designed a few years ago, before the long integer type I was
introduced into the BDE. I just tried changing those fields to type I, the error went away!
Comments by: Craig Butler
Date: 26 March 1998
What I'm trying to determine is the root of the problem. Is it the OBJECTPAL routine that does the update, the table index structure etc . For
example some time ago I discovered that if I in OBJECTPAL I set a range and then used the empty command to zap all of the records in that range,
and then added records to that range, after everything was done I sometimes ended up with a table with an corrupted index.
Comments by:Quentin Correll
Date: March 1998
I've discovered (Pdox 7.0, patch 4, BDE 3.5) that unless one uses the max block size of 32K there will be problems with large (wide?) tables at
around 180K records and 200+ MB table sizes! NONE of the intermediate settings will work correctly! ONLY the 32 MB block-size setting works
correctly!
Solution by: Jazz Rasool < jazrasATcommunicationwarehouse.com >
Date: 13 November 1999
Solution (1)
Try the ChimneySweep program available for a free trial from
www.sundialservices.com. It has
often recovered tables that the Paradox Table Repair facility could not.
Solution (2)
(1) Create a new table and borrow its entire structure from the corrupt table.
(2) Add the records from the corrupt table into the new table using the Add command.
Solution (3)
(1) In Windows File Manager or Explorer copy the .DB file associated with your table into a seperate directory.
(2) In Paradox or database Desktop, change the working directory to this directory.
(3) Open the table. If it is OK then simply restructure it to return it to the way it was.
Solution (4)
(1) See if you can export the corrupt table into a comma seperated or spreadsheet file.
(2) Import the exported file into a new table.
Solution (5)
Open the table from within another product-ie try and import it into Corel WordPerfect table. You can also try Quattro Pro, Microsoft Access,
Excel or Word.
Solution (6)
Defragment the drive with the original table on it and then try and open the table.
Solution (7)
Try renaming the table to an 8 character name.
Solution (8)
(1) Try running a query checking all fields so that it will extract all records up to the record that gives the error.
(2) Work your way up from the bottom of the table and see if you can find the end of the bad block of records. Again run a query to extract all
records after this point.
(3) Add the 2nd query results to the first and you should have your original table minus any indexes, lookups etc.
I have come across 'corrupt file other than header' errors and one of the above solutions usually recovered the table. There are other solutions
but this lot should suffice for now.
Other suggestions:
First try to repair the table with the Table Repair Utility. If that fails, then attempt to recover the data by doing one of the following:
- Do a CheckPlus query on all fields of the table.
- Save the table as a dBASE table.
- Export the data to a text file.
More information:
see current bugs PX0469
see current bugs PX0689
see fixed bugs PX0252
Problem 3: Getting error "Corrupt file - other than header." when importing text files.
More information:
see Documentation issues 80
see Documentation issues 81