>I see that now. Basically we have a bit field in SQL that is used for logical values. It allows nulls and the default value is false. Of course, it is a new field which we had with the update and new default values are set to false but existing records are left as null during the update. The majority of the records will have a null value. In most cases, we pull the record only if it is false or null, but not true. In our Select statemens we have:
>
>(ISNULL(inactive,0)!=1)
>
>when the result returned is filtered on only returning records that are not marked as inactive. Many times we have the field in a different result set though based on other queries and in that case we step through the result set in VFP and use:
>
>IF !(NVL(logicalfield,.F.)) && check for false
>
>or
>
>IF (NVL(logicalfield,.F.)) && check for true
>
>It looked in testing as if the nulls were behaving as false (which would be fine since the default value in the field is false) and didn't require the NVL(). I just wanted to be sure whether or not that would
>always be the case. In other words:
>
>IF !logicalfield && check for false
>
>appeared to work as well when the value was null and not false. I couldn't be certain though based on my limited understanding of how VFP handles null values in cursors. I was playing it 'safe' with the NVL() I think. I tested 65,000,000 records using both methods and the speed difference between the two was negligible. I've had strange result sets returned when the very first record returned contained a null value though (VFP would sometimes created a different field type instead of a logical field) so I wanted to be sure.

Here's a simple test:

?IIF(null, "true","false")
?IIF(not null, "true","false")

both return "false". Also,

IF null
	? "true"
ELSE
	? "false"
endif

does the same (also with not null). I'd just conclude that a logical expression behaves as false if it evaluates to null.