Federico,

It is *not* a VFP botch-up in the sense that there is a problem with the design of the product.

The "problem" is that we all (more or less) get the same rude introduction to Primary/Candidate keys because the documentation simply fails to mention *ANYTHING* about the impact of (marked) deleted (but still present) record's keys.

While it is quite easy to get used to, it does cause many a lot of grief until they figure out for themselves what is happening. The primary purpose of documentation is to save people from experiencing that grief, and MS fails miserably in this area as far as VFP is concerned.

Cheers,
Jim N

>I don´t know whether I´m missing anything, but I´m beginning to think that the CANDIDATE indexes (indices?) are about as useful as the old UNIQUE ones, at least if you work with SET DELETED ON.
>
>The following program should not (IMHO) produce an error, but it does:
>
> SET DELETED ON
> CREATE TABLE TRY (KEYFIELD N(3))
> INDEX ON KEYFIELD TAG KEYFIELD CANDIDATE
> INSERT INTO TRY VALUE (1)
> DELETE FOR KEYFIELD=1
> INSERT INTO TRY VALUE (1)
>
>What does this mean? For example, assume an user had (once) entered a record with a key value of 1, and later on he deleted it. If you list the table, the key 1 does not show up. If you try to SEEK it, it´s not there and FOUND() returns .F.; ok! But, after all that evidence, if you try to INSERT a new record with key 1, it fails!
>
>Am I missing anything, or is this just a VFP botch up? Opinions?