"Table XXX has become corrupted". And now? 1

[TheSofty]

Hi all,

it's the second time a client of mine calls me with a problem in his app. I see that I cannot open his files (two) because of the error in the header. I'm on VFP 8.0. I have NEVER had such a problem, much less two times in a row. Is there some tool somewhere to help me?

Thanks

 

[ramani]

If the header file is corrupted, it is very tricky.

If it is only rebuild ing index, I have some code under an FAQ to address this.
ReBuild your CDX index files
faq184-1033




ramani
(Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[rgbean]

You may want to go to

http://www.craigberntson.com/articles.htm

and read the article on "Avoiding Table and Index Corruption".

Rick

 

[TheSofty]

Ramani,

thanks for your routine. It'll be good for another need, but this time it's trickier. The first time it happened I knitted my eyebrows, but now I'm really worried. Is it possible that an error on my part somewhere can cause such a damage?

 

[TheSofty]

Rick,

thanks for your advice. Just went to Craig's site. Actually "Don't edit the data directly. Instead, use data buffering." could apply here. In fact I have a piece of code where I

...
SCAN
SCATTER NAME oRecord
INSERT INTO table1 (zzz,yyy,xxx,...) ;
VALUES( oRecord.zzz, oRecord.yyy,...)
INSERT INTO table2 (aaa,bbb,ccc,...) ;
VALUES( oRecord.aaa, oRecord.bbb,...)
ENDSCAN
...

No buffering. I never realized it was so dangerous!

 

[badukist]

It is not dangerous, (and shouldn't be).
VFP8 has a new setting, SET TABLEVALIDATE (default is 3)
If SET TABLEVALIDATE TO 3, VFP checks the record count in header when the table is opened or records are appended against the real number of records stored in file ((filesize - headersize) / recordsize). If the number is not the same, then the table header is corrupted.
In prior versions you could work normally, this wasn't checked.
This header record count corruption can be caused by incomplete updates (client app/system crash, corrupted network packets, server crash/reboot). The record is inserted, but the header is not updated with the new record count.
You can try:
SET TABLEVALIDATE TO 0
USE table
PACK
USE
SET TABLEVALIDATE TO 3
USE table

Note (check this): I believe that if the record count in header is 2000 and the real number of records is 2010, using PACK or COPY TO you will recover only 2000 records
I don't know for sure, maybe other know this better

Another option is to fix header using low level file acces functions ( FOPEN(), FSEEK(), FWRITE() ) and write the correct number of records in table header.

Again, I only heard about this, I don't know how can be done and I don't have code that do this.
The table header description can be found in help
byte 0 : table type:
byte 1 - 3 : Last update (YYMMDD)
byte 4 – 7 : Number of records in file

Maybe other experinced people from here will help more.

 

[TheSofty]

Badukist,

thanks for your information.

I had forgotten about this new addition (SET TABLEVALIDATE) in VFP 8.0 and its use. If you say that that code snippet isn't too bad, it leaves me with an unpleasant feeling: "So, what possibly can cause such a problem?".

I'm on XP Pro here, and my client is on Win98SE. I have dozens of users of other apps of mine on Win98SE that (fortunately) don't have this issue. Can a driver (printer, graphics...) cause this?

 

[badukist]

If an app terminate unexpectedly because faulty drivers (video, printer) or power loss,this can happen, even they have a rock solid server.
Also default network settings (client or server side) like locking, caching, etc, can lead to table corruption. It is a "neverending story" for all applications that use shared database acces.
A lot of concurrent users inserting/updating records in a table can also cause this.