Heya Grig!!! Long time no see!!

That was a great explanation on why to use NULLs. Better than mine. =)

~~Bonnie



>Hello, Kevin
>
>I've read an article somewhere (I can't remember the autor) that was giving the following example:
>
>Suppose you need to calculate average age in a table. Age is entered by hand (is just an example). You have 10 people in the table, but only 7 of them agree to give their age.
>
>In non-null approach, the age of those three people is 0, which affect the average (it will be smaller).
>In null approach, AVERAGE() will ignore the nulls and it will calculate the average only for actual data.
>
>In other situations, you may need to check for nulls (they propagage in math calculation, ie 2 x NULL = NULL), but VFP has a very handy function that helps: NVL().
>
>Bottom line, NULL means "I don't know". How big is NULL? "I don't know". Null.
>Is NULL = NULL? Answer: I don't know. Null.
>How much is NULL + 7? I don't know. Null.
>
>Aggregate functions (Average, Count, Max, and so on) are NULL-aware and gracefully skip it. For the rest, you need to check NVL().
>
>Ahh.... almost forgot. When it comes to calendaristic dates, NULL support is he best. If you have a datetime column in SQL server, that does not support nulls, and insert an empty datetime value through SPT or remote view or CA, sql server stores it as 01/01/1900. I'm not sure you want to see that. :)
>
>Hope this helps.
>
>>But you then have to check for nulls, as opposed to just
>>saving the field values.
>>