>>In some cases null is a must. Consider a lab result, where null means "was not done", and zero means "done, none found".
>
>IMHO, this business logic should never be used like that. A status field should be used, which allows, by the same, the possibility of additional status.

When I designed lab result tables, there was one row per value; measurements not taken didn't even have a record. However, I've seen tables with dozens of numeric fields describing various parameters measured or calculated. There should be at least a byte-mapped character field where each byte would be the status of the corresponding field (a technique not too different from bit-mapped fields, and actually similar to how Fox knows which field is null). But in the case of the current table design, it's either allowing for nulls or doing a lot more coding.