> I do not think this definition for NULL is limited to MS. It has, to the > best of my knowledge, the identical definition in DB2. > > And there is sometimes importance in distinguishing, as the chestnut about > entering a HEART RATE of 0 vs NULL testifies. In that case I would agree. In the work that I do, I disagree. One of my customers is the Bedford Institute of Oceanography (similar to Woods Hole in the US). They do measurements of various things in the water, primarily Salinity and Temperature, but they may also measure certain chemicals, etc. When they want to put all of this information in a denormalized table, they have standard fields for date/time/location/depth, plus one field for each of Salinity, Temperature, and each other thing that they were measuring. In this case you don't want to fill in 0 for a value, since that's valid in a lot of cases. You also don't want to throw in .NULL. since that'll screw up any calculations without a lot of precautions. In this case, the .NULL. would be more suitable as 'there is no value', since, for the most part, the value wasn't measured. There wasn't a 'lost' value anywhere, it just never existed. I suppose a similar example is my heartrate over the past 35 (or so) years. Something before 30 years ago, there just plain wasn't a heartrate. Not that the rate was 'not known', rather it just wasn't there. Perhaps it's time for a new SET command (scoped to a single field or memvar): SET NULL TO NotKnown | NoValue <g> /Paul