Josh,

The "Effective Techniques for Application Development with VFP 6.0" (Booth/Sawyer) has a good discussion on this (pg 24).

1) In the case you describe, after changing "A" to "B", and assuming that there are *more* "A"s in the table, the next "A" will *NOT* be shown/visible/accessible (until a reindex is done).
Of course, if you *add* an "A", then you will see that one, though it will change after a reindex because it will not be the first physical record with that key (assuming more exist).

2) If you DELETE the record with "A" and have SET DELETED ON, then no "A" will be accessible even though others may/do exist.
Even with SET DELETED OFF, assuming that your program does not want to process deleted records, no other will be accessible, though existent.

Cheers,

Jim N

>OK, now I'm totally confused. After re-reading the docs it appears that if you have a record with a key value of A, change it to B, then add a new record with key value A it won't appear in the index. However, a quick test doesn't bear this out. It seems like there is always one record in the index per key value without reindexing.
>
>Anyone?
>
>>I don't think you made a mistake. IMO, what Help says actually means non-maintained (at least from common sense point :).
>>
>>>Oops, my mistake. I think that's a leftover piece of information from FP 2.0 or maybe even FoxBase+.
>>>
>>>>I disagree with your statement "Unique indexes aren't maintained." From the help:
>>>>
>>>>When a UNIQUE index or index tag is active and a duplicate record is changed in a manner that changes its index key, the index or index tag is updated. However, the next duplicate record with the original index key cannot be accessed or displayed until you reindex the file using REINDEX.