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

Randy, it is so clear that don't know thing anymore to write.

A simplification.

This do the same operation with Replace and Update,
REPLACE put NULL into F1 without problems
UPDATE perform the same operation and fail

LOOK the FOR .F. !

CLEAR

CREATE CURSOR testDefault (f1 I NULL)

INSERT INTO testDefault VALUES (0)

INDEX ON F1 FOR .F. TAG T1 CANDIDATE

ON ERROR 
TRY
	REPLACE ALL f1 WITH NULL
	? "REPLACE DON'T FAIL"
CATCH
	? "REPLACE FAIL"
ENDTRY

TRY
	UPDATE testDefault SET F1 = NULL
	? "UPDATE DON'T FAIL"
CATCH
	? "UPDATE FAIL"
ENDTRY