I've seen lots of FoxPro programs that use GO TOP before a SCAN loop and SELECT just before the ENDSCAN and before every LOOP statement. These statements aren't required anymore. Yet, many developers use them as a safety belt. So what does SCAN really do? Here are a number of observations:

VFP doesn't store NULL in the field itself. Instead it uses a hidden field called _NULLFLAGS. You might wonder (well, I didn't, but you might) how VFP can create an index on a column that contains NULL, if NULL is not stored in the field itself. The answer is actually quite simple. A field that contains NULL is stored as a blank string. To distinguish NULL values from real blank fields, VFP precedes any other value with CHR(0x80). Hence, in Northwind\Customers.CDX the index on city contains "_PARIS" instead of "PARIS".

Unless I've been missing something in the past there's no native way in C# to compare byte arrays. Well, you could compare their hashes. But that only tells you if they are different. To make sure they are equal, you need to compare them byte by byte. Hence, using hashes is not only slow, it's also pointless.

When you read about repairing indexes in FoxPro forums, you frequently get the advice to avoid REINDEX. The most common reasoning is that REINDEX depends on the header which might as well be corrupt. That's true, but like most developers, I haven't seen a corrupt index header in years. The header is only updated when you add a tag. As this requires exclusive access to the table, there's little chance of introducing corruption due to caching, multi-user issues, and the like.

When you add a record or modify an indexed field, you expect to find them on any computer that runs your application. The simplest approach would be for Visual FoxPro to read the CDX file every time you search for a record. We can call this the Java compliant mode because when you run your application you would have enough time to get a new cup of coffee.