Table Corrupted

[Froy]

I'm having problem with a table that are corrupted and can't be fix. it's 36 Mbs, with 1.011.167 record.
Everytime I browse to the last record it will say in the status bar "Corrupt File-other than header. Table:tablename.db".

Later I found out that if the file is not indexed that it will be fine. But once I put the index again, it will give the error message again.

I tried using the table repair, create new table from scratch and copy one by one but still if I put the index it will say the the same thing again.

Help please.


froy

 

[Kliot]

You didn't mention if "table repair" gave you any errors, if so what were they?

Have you tried deleting the .val file that is associated with the table? A corrupt validity check file can give strange problems like this.

There are 3rd party utilities that do a better job than "table repair" but I haven't used any in years so I couldn't recommend one, someone else out there probably can.

It sounds like the file is intact so I doubt that you will have to go to that extent. I would start by copying the .db file into a new folder, copy it with a file browser not through paradox. Then try "table repair" and see if you get any errors and put the index back on the table. If that doesn't work you can also run a query for all the records and create a new copy of the table that way, if the table is in bad shape the query won't run but if it does that's another option for re-creating the table.

I hope this helps, keep us posted.

Perrin

 

[Froy]

Thanks for your reply.
The table repair didn't give any error message, so I assume that it can't detect the problem.

I've use chimneySweep 4.0 but it didn't fix that as well.

I did copy the table using file browser and then try the table repair, and it didn't give any errors, but when I put the index by restructuring, then I will have the same error message when i browse to the last record. That is the same result that I get using the query as well, once I put the index that it's corrupted again.

I've even create a form to create new table and then using Tcursor, copy all the record one by one.
There is keyviolation.

btw, it's paradox 7 table.
and the structure of the table is :
rec_no I *
field1 I
field2 A20
filed3 A4

froy

 

[Kliot]

Strange, have you tried converting the integer fields to numeric fields? It seems like there is strange data in one or more of the fields, I'm wondering if Paradox will pick up the problem my converting the field type.

Perrin

 

[footpad]

Froy,

If you have data that can't be fixed, your best bet is to export as much data as possible, create a brand new table structure, and then import your data into that.

This usually isolates the record(s) that are causing the problem. In many cases, the corruption is in one of the support files, such as the .MB file.

However, your structure doesn't appear to contain any of the types that use an .MB file, so it's unclear why you'd be having problems.

Depending on the version of Windows you're using, it's possible that the index file is being corrupted on the fly due to the write-behind caching that's now enabled by default. For additional details, please see

http://bdesupport.com/stability.htm

and other pages on that site.

Hope this helps...

-- Lance

 

[jlockley]

None of the above, I suspect. That one cost me a week of annoyances and probably a year off my life.

Let's go on to guess that your table is part of a larger database with lots going on. The thing is that Paradox, when you start manipulating large amounts of data or changing structure, has the odd propensity of trying to put the entire thing, lock stock, form, scripts, querries and barrel into cache while the process takes place, so what you have to do is fool it. The answer is easy but a but cumbersome:

Copy only the table including *.px, *.db and *.mb plus anything else you absolutely need to change or manipulate into a separate directory - leave the cousins, neices, great grand children and aunts back in your working directory. Now try the same process. I am sure you will see that everything works just hunky dorey.

 

[footpad]

jlockley,

This is more of a factor of the OS than a factor of Paradox. While there are membery buffers that are used, BDE actually manages them surprisingly well...in later versions, at any rate. I would verify that you have at least 5.11 or 5.12. (How to check? See

http://techtricks.com/paradox/bdeversion.php;

there's a trick involved.)

If you're running into problems with this, verify that your OS and network software isn't trying to cache things, too.

Hope this helps...

-- Lance