Richard,

You addressed Paul, but I wanted to respond too.

I agree with you that it *IS* inconsistent to report type "O" but ISNULL=.T. I can only guess that MS want to imply that an object cannot be "empty" other than NULL. Perhaps it has something to do with subsequent instructions which might try to reference the (not really existent) object???

Oh well, not the first time VFP shows inconsistencies

Jim N

>Paul,
>
>I agree that .NULL. can be a strange animal. But I also agree with Jim Nelson that Microsoft's view of .NULL. is correct. It's nonetheless inconvienent. What we need is a way of converting .NULL. to a value such blank or zero when this is appropriate (as in your SUM() example) . SET NULLDISPLAY and the NULLDISPLAY property are steps in the right direction, but these only affect the way .NULL. walues are displayed. This doesn't help in calculations.
>
>My original point about .NULL though. referred to the fact that an object reference can return a TYPE("oMyObject")="O" and at the same time ISNULL(oMyObject) = .T.. This seems inconsistent. If the object exists, shouldn't ISNULL(oMyObject)=.F.? If the object doesn't exist shouldn't TYPE("oMyObject")="U"?
>
>Richard Danley
>Tri-B Computer Systems