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.

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

>This is a sample ( and this is not a a bad pixel bug.), and I can recover many others of it.
>Post to Randy on Thread #1005504 16/4/2005
>
>Then, or I am the only one to find bugs (I don't believe it)
>or for extrapolation, how many are the not fixed bugs?
>
>

>SET NULL ON
>
>CREATE CURSOR testDefault (f1 I NULL DEFAULT NULL)
>
>* PUT A NULL
>INSERT INTO testDefault VALUES (NULL)
>&& NO PROBLEM WITH THE EXISTS NULLS
>INDEX ON F1 FOR NOT ISNULL(F1) TAG T1 CANDIDATE
>
>REINDEX
>
>&& no problem with these updates
>
>REPLACE f1 WITH f1
>REPLACE f1 WITH 1
>REPLACE f1 WITH NULL
>
>BLANK DEFAULT
>
>&& BUG ON THE CHECK ORDER, AND THIS FIRE A ERROR
>UPDATE testDefault SET F1 = F1
>
>&& BUG ON THE CHECK ORDER, AND THIS FIRE A ERROR
>INSERT INTO testDefault VALUES (NULL)
>
>&& WITH APPEND too
>APPEND BLANK
>