At BSO, every few months we have weird problems that we attribute to index corruption. In other words, most of the time it works well.

First of all, you should use structural indices - create indices with the TAG clause, not with the TO clause. Otherwise, you might get index corruption "every time you open the table", namely, if in some place you forget to open the index files. With structural indices, they will be opened automatically.

It also helps to issue the FLUSH command after making changes. In Visual FoxPro, that would usually be after the TableUpdate() command.

Modern versions of Windows use a write cache; if you turn it off (in the hard disk properties), you will reduce the chance of corruption (especially if the power fails), but you may also drastically reduce performance in general.

>A long time ago, I developed a data entry system with VFP-5-DOS. The indexes were so fragile that I had to reindex everything each time the user started the system and I added a global reindex facility for use when the indexes became corrupted during data entry.
>
>For most of the last decade, I've been using VFP as a data engine for data warehouse apps. Data uploads were so large that I routinely dropped the indexes, added new data and reindexed the tables. Therefore, index corruption was not an issue.
>
>I'm looking at a client that wants to develop a new n-tier app using VFP as the business tier and the data tier. The initial interface tier will be VFP, but the client wants to be able to add a web interface at a later date.
>
>I'm concerned about the fragility of VFP-9 indexes and am considering advising the client to move to a SQL Server data engine. For the size of the database, the app would be better served with the VFP engine, but my (ancient) experience makes me leary of VFP's indexes.
>
>Regards,
>Thom C.