Hi Christof,

Interestingly, Chaim reports that after getting the error a simple restart of the application proceeds properly with no sign of any index error.

While I can agree that this still could be a hardware error somewhere along the path, the fact that no permanent damage is done (indexes still all OK, no rebuild required) suggests that other factors are (also) involved.

cheers


>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.