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