Table Corruption

OK Friends,  I need enlightenment, guidance or magic...

I have a an application running PDOX 11.  I have deployed this application to roughly 250 customers.  All customers have their own local database.  This application (or some form thereof) has been deployed this way for over 20 years. My point,  it is not new.

This is the problem

I have one specific customer,  (PDOX11, Windows 10, database is on the C drive )

There is one table that is persistantly corrupted for this costumer.  The table has roughly 250,000 records.

I can repair the table and they go about thier business for a time, In the past 3 days I have repaired the table three times.

I have found no perceivable difference between her table structure and that of other customers.

Diagnostics to data:

I have copied her data from her table into another NEW table.

The user has had a new PC installed (there were no issues for about 2 months after the new PC was installed)

lots of table repairs.

Anyone have another idea?

SMB, file locking issues or Anti-Virus

Jeff

Also,  I would add,  the KEY structure on this table is fat (8 fields) 

is the "corruption" just the indexes? is the table size more than 1/2 the max, for that block size?

query out the data to a temp table.. run tutility or chimney sweep on it.. export to ascii.. make a new table from scratch.. import the ascii.. run tutility or chimney sweep on it.. add the indexes, pack the table

literally, do it all from scratch

Steven Green
Senior Software Engineer
Paradox Support Specialist DOS/WIN

Please confirm this statement
" is the table size more than 1/2 the max, for that block "

I believe you are referring to
Paradox tables hold a max of 65536 blocks, which can be block sizes of 1,2,4,16,32kb therefore the max sizes per table can be (in approx sizes):

1kb blocks - 64Mb
2Kb blocks - 128Mb
4Kb blocks - 256mb
16Kb blocks - 1Gb
32Kb blocks - 2Gb

In this users problem table: 

The block size is 32

The record byte size is 207

24 Fields

The file size on disk is 86,210 KB

I will work on your steps,  However I dont have Chimney Sweep,   but I might have the tutility.

However,  I don't see how this is any different than taking a virgin copy of the table and inserting the records,  which has been done.

Thanks

Jeff

> Please confirm this statement
" is the table size more than 1/2 the max, for that block " <

32k blocks, table has a max size of 2 gig.. sec indexes become disfunctional if the table is over 1 gig.. this particular table is only 86 meg, so no issue

> I will work on your steps,  However I dont have Chimney Sweep,   but I might have the tutility. <

tutility is the built in repair tool.. CS catches some advanced stuff, sometimes, that tutility doesn't.. an actual Repair catches many things that Verify doesn't even see.. it's all art, not science, unfortunately

in this case, what are the actual symtoms and/or error messages in the app that become the source of the problem?

in this case, other than the stupid "low ascii" errors, what errors does Verify give you?

> However,  I don't see how this is any different than taking a virgin copy of the table and inserting the records,  which has been done. <

if there's a bad pointer in the file, or a bad block on the disk, the ascii export process will often be "cleaner" than simply adding the records from the bad table to the empty table

if there's a "bad block" error in Verify, or something similar, and it's' still there after you go thru all the hoops I suggested, now you'll know you're doing the same "rinse and repeat" that won't go away

yes, I've seen that happen.. recently, I had a table like that.. trial and error, narrowed it down to one block of data.. added a record that split the block, the error moved to the new block.. deleted the new record, packed the table, it moved back.. deleted the "offending record", the next record error'd out.. kids, don't try this at home :-)

Steven Green
Senior Software Engineer
Paradox Support Specialist DOS/WIN

Probably way too late, but this is a known bug using 32k blocks - go back to 16k and it will likely be fixed.

It's bug "PX0469 Tables - Table Corruption" on Bertil Isberg's bug list with full description.

I hit many similar issues and reverted back to 16k blocks and its been rock solid (mostly ;-)

-David

Peace,
David Cheney

a Short in a compound key can cause corrpution, in any block size.. but especially in 32k block

Steven Green
Senior Software Engineer
Paradox Support Specialist DOS/WIN