Most of the times you won't get real corruption, the table header will get damaged and you can fix it with these tools. Besides, if the index is what is corrupted, the you can rebuild it, you won't loose the data.

In the case where the data gets corrupted in deed, with some tools (for example DBF Doctor) you can "edit" the file and try to discard the bad records. Unless your table has little data, is very difficult that all your data gets corrupted, as the corruption affects to the data that was written when the disaster ocurred.

>What does that have to do with the effects of corruption.
>
>>Most of the times you can fix corruption problems with 3rd party tools (StoneField, DBF Recovery, FixFox, ...)
>>
>>>Hi,
>>>When there is corruption, anything is possible.
>>>
>>>>Hi
>>>>Can I understund clearlythat never VFP will not go to other line because index problem?
>>>>
>>>>>Hi Chaim,
>>>>>
>>>>>>1. Is the index problem can cause VFP to go to other line (and to edit/insert/delete) or only to give .f. to the seek?
>>>>>
>>>>>Index problems can crash VFP or trigger the error handler.
>>>>>
>>>>>>2. My problems frequentness will grow according my database/files size?
>>>>>
>>>>>Not necessarily. It more depends on the number of changes you make to any data file. The more changes the more people make, the more likely is an index corruption. In many cases, though, hardware or system configuration have a huge impact on VFP's stability.
>>>>>
>>>>>>3. What is the maximum lines/size in tables/database?
>>>>>
>>>>>A little less than 2 GB for a DBF file, 2 GB for the FPT file. The same limits apply to the DBC file itself. As for the number of tables, I'd be careful with any database that has more than 32,000 tables.
>>>>>
>>>>>>4. If I will go on SQLserver, I will not get other problems?
>>>>>
>>>>>You definitely will get problems in many areas. However, it's much easier to stabilize a single MS SQL server than it is to ensure integrity across all clients and a file server. With SQL server you still have to backups, you have to keep updated on service packs, you need someone familiar with SQL server at the client side in case of a problem, etc.