Thomas,

Thanks for your detailed reply..

I'm not really talking about any 1 table or network

This particular problem I have encountered is from a table in Nestle Syria

But it's a more generic find and fix routine I am working on.. I am upgrading 200ish countries to a VFP app and want to verify their data is stable before continuing..

I may end up deleting the CDX from every table.. trapping the error message.. then re-creating the index (the last part I am doing anyway)

I suppose another way round this is to find a way to open a table without an index, There is no use noindex clause :( and I've already checked out set optimize the cdx still gets opened.

But in reply to you message.. yes you are quite right.. the biggest cause of corruption is users and networks.. but I have 10 years worth of user and network history to contend with <g>

Will

>>Afternoon all (Morning for some of you)
>>
>>I have a table which has a corrupt index expression
>>Ie there is an index in the table which points to a field which does not exist
>>
>>Each time I open the table it gives an error "Variable 'OD_CD' is not found." (In fact it should be prod_cd)
>>
>>It's easy enough to fix this issue.. I could just do a delete tag all & recreate (or similar)
>>
>>But I was wondering how do I detect this kind of issue programatically?
>>If I do something like the following:
>>

>>llFlag = .f.
>>On error llFlag = .t.
>>Use table in 0
>>
>>If llFlag
>>  Wait Window 'Error occurred'
>>EndIf
>>

>>the flag is not set correctly & a VFP error still comes up, which I don't want my users to see.
>>
>>Does anyone know of a way to either trap for this kind of error or detect the issue in the dbf? (I can see a million suggestions for SDT coming in my direction)
>>
>>TIA
>>
>>Will
>
>Will;
>
>Sergey brings up a good point about CDX corruption. Watch your network – Hubs, Switchers, bad connectors/cable – and use a UPS on your computers. Then train your users – that is a HUGE variable! No, do not turn off the power of the server or your computer in the middle of an operation. Gee, why not?
>
>To me it sounds like you have some bad code somewhere. Something is corrupt and it will be a task to find and correct it. It might be within the dbc as you are picking up an incorrect index tag. Did you ever have such a tag, and delete it? Could you be pointing to another dbc with the same name? I have see strange things.
>
>If you throw a defined (by VFP) numeric error you can place that in your OnError routine and do a call to SDT to repair the problem on the fly, or manually if you prefer.
>
>Once you find the source of your problem it is a good idea to include the use of SDT. There are many ways to handle issues like this:
>
>1. Do nothing – because nothing will happen. :) (pray a lot)
>2. Worry about it at 2 AM when the client calls you. Until then it does not matter.
>3. Build your applications to include table/index repair, regardless of how “small” they are.
>
>Application requirements differ. Some apps are fine with a manual index repair, others should have a seamless automated repair function and still others will rebuild all indexes upon startup. Again this is all according to system requirements. There is never “one way to do anything” unless you walk on water.
>
>Your client is entitled to data that has not been corrupted because of development oversight. The developer accounts for reduction of all things under his/her control that negatively effect software and data integrity. Great theory and it sometimes works!
>
>Hope you find the cause of the problem.
>
>Tom