I may not be following your logic here (it may be communication problem) so it is best to provide a good sample with "observed" and "expected" results.

Looking at the original message and your follow ups, I see indexes with FOR, Candidates and Nulls involved. Based on the current behavior I see that the following error message will get triggered for a candidate key "regardless" of any FOR expression.

Index does not accept NULL.

Based on the FOR expression behavior (excluding use of nulls), I see what you indicate -- that the FOR expression is first checked before key is updated.

Because null usage appears to be checked well before the FOR expression, you should not expect the behavior you are seeing to be a bug. There are different error checking going on in the product are different points along the code path. For the case with nulls, this is "field" dependent, whereas with the case of an Index FOR expression, it is "tag" dependent.

Again, if you still think there is a very legitimate bug here that the team would not consider something as a design issue, repost the bug with very clear and concise steps along with exact values/results that you observe and expect.

RB

>>Fabio,
>>
>>I don't know if this issue was ever reported to the product team. Just because you chose to post messages to me in the past on a public forum doesn't mean that I ever received or read them (which is the case with this one below). It may be that someone else on the team picked it up, but this one does not look familiar to me.
>>
>
>I known this.
>
>>As for your specific issue below, my take is that you are trying to prevent the "Index does not accept NULL." error from occurring by having a FOR expression. The current product behavior is to prevent nulls from being inserted into a field with a candidate such as following:
>>
>> CREATE CURSOR testDefault (f1 I NULL DEFAULT NULL)
>> INDEX ON F1 TAG T2 CANDIDATE
>> APPEND BLANK
>>
>>It appears to me that key filtering (FOR expr) occurs after the new key is created, which looks to be by design.
>
>This is not true.
>
>For the commands INDEX ON and REQUERY
>the FOR expr occurs before the key insertion,
>because the insertion is not done,
>( try to build a INDEX ... FOR .F., it start empty!)
>
>When the index is updated the key is inserted
>and after the FOR filtering is applied.
>
>Even if this didn't produce any anomaly,
>for me this is a bug.
>My example shows where the bug manifests him.
>
>Call it by design, by programming, by what you want, but this is a bug for me.
>
>Of course you can say that this is declarative and VFP is free to do every thing
>on every possible way.
>But with this logic, you can say that
>1+2=2+1 is false and it is correct.
>
>Fabio
>
>>You may disagree, but it appears to be how product indexing was designed (intentionally or unintentionally). If this >behavior is new to VFP9 and did not exist prior, then you have legitimate concerns. Otherwise, I would be inclined to >consider this as more of an enhancement request (something not likely to be addressed for SP1).
>>
>>Randy
>>