Hi Fabio,

I agree, it's a serious bug. Here're some more observations. Run following code

SET NULL OFF
CREATE CURSOR testDefault (f1 i NULL DEFAULT NULL)
INSERT INTO testDefault VALUES (NULL)
INDEX ON F1 FOR NOT ISNULL(F1) TAG T1 CANDIDATE
* #1 - the following BLANK doesn't fail even w/o DEFAULT clause
BLANK 		&& DEFAULT
* #2 - ignore the error
UPDATE testDefault SET F1 = F1
* #3 - Index is corrupted at this point
*      Error on the BROWSE command : Index does not accept NULL.
BROWSE LAST NOWAIT
RETURN

>Expected: if the index's FOR filter remove nulls values,
>a candidate index have to not fire a error
>
>Observed: when a NULL value is inserted/updated
>VFP can fire a error
>
>

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

>
>It prevents to the use of keys candidates for not null values,
>one great function, absent also in MS SQL 2000.
>
>I hope it is fixed in VFP9 SP1.