That's not what I meant. I mean that if you delete the key that's in the index, it is no longer indexed on that key. I'm not sure what it would do if you did UNIQUE FOR !DELETED(). It might replace the key in the index then, but I'm not sure.

-Michelle

>Michelle,
>
>That's true. INDEX ON pays no attention to SET DELETED. This can also cause problems with PRIMARY and CANDIDATE indexes. You can deal with this using INDEX...UNIQUE FOR !DELETED().
>
>>I think the thing with uniqe indexes is that if you delete the record that is in the index, it won't automatically stick another it.
>>
>>For example: Indexed on custname uniquely. There are 5 John Smiths. You delete the John Smith that is the one in the index. There is no longer a John Smith in the index, even though there are 4 others in the table. If you reindex, you pick up one of the others.
>>
>>-Michelle
>>
>>
>>>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.