The unfortunate part of Unique index 'maintaining' is that if you have 2 records with the same values in unique expression and then the record really pertained to the index gets deleted, then another one will not appear (e.g. in Browse) until table will be REINDEXed. It indicates that relying on Unique index in real application (where REINDEX is not used often) may potentially fail miserably or force developer to take serious precautions in using this index. So, basically, unique index is not useful thing for development and can be used for really ad-hoc operations only.

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