Opening tables created in FPW gives 'table corrupted' error but only with a few 2

[Rajesh Karunakaran]

Hi Team!,

When I try to USE and read from tables created in FPW/dBase (DOS) from within VFP, only with a few tables it gives 'table is possibly corrupted and need to be repaired before using' error. This happens only with a few tables while many tables in the same set are okay. Interestingly, when I use this in FPW, it opens without any issue. But, I am not able to understand or figure out why it gives error in VFP.

What could be the problem?
Are there any known issues or environment we need to set to avoid this?
Does this something to do with the CODE PAGE or similar properties?

Can someone suggest?

Thanks,
Rajesh

 

[Mike Gagnon]

https://www.tek-tips.com/viewthread.cfm?qid=1162025

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Tore Bleken]

That's because VFP has become less and less "forgiving" with errors in the tables for each version. With earlier versions you didn't get any warning, and all of a sudden you could lose much of your data. In the later versions you get a warning and the chance to fix the errors before disaster happens.

 

[Rajesh Karunakaran]

Hi Gagnon,

I went through that thread and Mike Lewis answer is very clear.
For me, the FPW/dBase tables which I am not able to open are
- not in a DBC
- not being structure modified
- not being assigned any code page when I USE it.

I am just opening it by
USE <table name> IN 0 ALIAS pt
Its a copy of the actual tables and they are independent in my system, ie no application is using it.

However, I am able to open it in my FPW

Not able to understand the reason!

Thanks,
Rajesh

 

[Tore Bleken]

The reason is some kind of corruption and/or mismatch between the info in the header and the actual data. If you have VFP9, check Set TableValidate in Help for a description of the most common reasons for this.

Simple fix: Use the tables, one by one, and run Copy to newfolder\samename with cdx. Then copy the files from newfolder over the old files.

NB! Don,t, I repeat DON'T, be tempted to Set Tablevalidate to 0. That will stop the error messages, but it will also make your system fragile.

 

[Mike Lewis]

If Tore's advice doesn't solve the problem, try this:

1. SET TABLEVALIDATE TO 0 *see note below

2. USE the bad table

3. COPY STRUCTURE TO a new table

4. USE the new table

5. APPEND FROM the old table.

6. Delete or move the old, and rename the new.

7. SET TABLEVALIDATE TO 3

* I note what Tore said about never using TABLEVALIDATE 0. That's generally good advice. But, in this case, it's OK provided you only work with the corrupted table and don't open any other tables (except the new one that you are creating). And be sure to keep a backup before you start.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

And if that doesn't work either, try one of these table repair tools.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Tore / Mike,

Let me follow your suggestions!
Will get back here with my observation.

Thanks
Rajesh

 

[Rajesh Karunakaran]

Tore / Mike,

Thanks! That TABLEVALIDATE did the trick.

I have around 1000 tables, a few among are problematic. I am using a small prg to process these tables.
In the PRG, I added a 'patch'. If the table was not opened the usual way, then I set TABLEVALIDATE to 0 and open it. Then, immediately I set it back once the process is over. This is what I have done. I processed all the tables.

Thank you very much for your time!
Rajesh

 

[Tore Bleken]

You're welcome! I'm glad that your problems are over.