"Is there any function that can distinguish [the zero and the apparently blank entry]?"

Look at ISBLANK.

CREATE CURSOR Dummy ;
(nDummy N NULL, nValOfDummy N NULL, lISBlank l, lISNull l, lEmpty l)
APPEND BLANK
REPLACE nValOfDummy WITH nDummy, lIsBlank WITH IsBlank(nDummy), ;
lIsNull WITH ISNULL(nDummy), lEmpty WITH EMPTY(nDummy)
APPEND BLANK
REPLACE nDummy WITH 0
REPLACE nValOfDummy WITH nDummy, lIsBlank WITH IsBlank(nDummy), ;
lIsNull WITH ISNULL(nDummy), lEmpty WITH EMPTY(nDummy)
APPEND BLANK
REPLACE nDummy WITH .NULL.
REPLACE nValOfDummy WITH nDummy, lIsBlank WITH IsBlank(nDummy), ;
lIsNull WITH ISNULL(nDummy), lEmpty WITH EMPTY(nDummy)

BROW


>>>>>>I have a numeric field with no default value that allows .NULL. values. The users say that "blank", as they would call it, means "undefined", which is why I allow null. I noticed that if you delete the number in the text box, it fills in a 0. I gather that blank and 0 are the same thing in a numeric field, and that EMPTY(numericfield) returns .T. if it's a 0. If the record is saved without anything being typed in that field, you don't see a 0 on the form or in a browse window, but it seems to get treated as a 0 by vfp functions, and ISNULL() returns .F.. Am I correct that the 0 and the apparently blank entry are really the same thing even if they don't look like it? Is there any function that can distinguish them?
>>>>>>
>>>>>>I gave the users a button that enters .NULL. in the field so they wouldn't have to type that in the box. That seems like a kludge. Is there a better or more standard way to facilitate null entries in numeric textboxes?
>>>>>
>>>>>0 and apparently blank are not same if one is initialized to null. If nulls aren't allowed they would be same. Sometimes this catches you in a control :
>>>>>if oldval(..) = curval(..) && Oldval is null for a new record
>>>>>&& Or an explicit "insert into ... values (.null. , ...) might be executed
>>>>>&& and nulldisplay = ""
>>>>>By default "nulls" setting insert nonnull (empty) values.
>>>>>Cetin
>>>>
>>>>I did a test query to make sure of this. Nulls are allowed, but the new records are not initialized to .NULL. or anything else (though perhaps they should be). Here are some typical results:
>>>>

>>>>quantity  EMPTY(quantity)  ISNULL(quantity)  quantity=0
>>>>
>>>>4         .F.              .F.               .F.
>>>>.NULL.    .F.              .T.               .NULL.
>>>>0         .T.              .F.               .T.
>>>>(blank)   .T.              .F.               .T.
>>>>

>>>>
>>>>The "blanks" seem to behave exactly like 0, but I don't see 0, and, more importantly, the users don't.
>>>>
>>>>That tidbit about using Ctrl-0 to input .NULL. was interesting. I didn't know it, and my users probably didn't either. It doesn't seem to work in Access, so I guess that it's not a Windows standard. I think I'll leave my "null input" button there until there is a better idea.
>>>
>>>No it's not a windows standart but VFP. What about "set null" although it doesn't effect all commands (effects SQL commands).
>>>ie:
>>>set null on
>>>insert into mytable (field1, field3) values (1,"blahbla")
>>>would insert .null. to field2 (not included in insert list). Fields should be set to allow nulls.
>>>I always use "insert-SQL" for new records so this works.
>>>Cetin
>>
>>I suppose I should give that field a default value of .NULL. one way or the other. So, how would I get rid of the "blanks" that are already in the table without editing each one manually? If the users meant for those to be 0, I can use this simple, rather silly looking statement: REPLACE ALL quantity WITH 0 FOR quantity = 0. But if they wanted them to be .NULL., which is probable, how can I turn the blanks into nulls without also turning all the zeroes into nulls?
>>
>>...and how can the blanks not look like zeroes in the first place?
>
>Behaviour is just like that since FP 1.0 AFAIK. I never looked at lowlevel for that purpose and for now don't have an idea how to distinguish a 0 from a (blank). Might (blank) all spaces (chr(32)) at lowlevel. I'll check when I can access my own computer.
>If I assume it's distinguished some way, then setting to .null. is "replace .. with .null. for empty(quantity)" - empty() to be another udf() distinguishing it maybe.
>Tomorrow I'll check this again.
>Cetin