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