>>In most applications you don't care the difference between a null or "" or null and 0.
>
>Well, I do, if it is necessary. The difference to an empty date or datetime field is, that "" or 0 re regular values for their particular types, but {//} isn't. You cant do anything with an empty date value. A zero is a regular value for a numeric field. The zero tells me some value, but what does a {//} tell me?
>If the zero is not valid for the special case, I would recommend using the NULL as well.
>
>And in this special case another problem comes into the game. If you query a VFP table with date fields via ODBC, all empty date fields will show December 30th 1899 as their value. How can you distinguish between empty date fields and fields that really contain this value?

Yes as I said before you should use null if it matters.
For empty datetime underlying value is not (//:) but 0.0, //: is only a display format. IOW you are also pointing to the root of problem. They chose a regular 0.0 to mean a base datetime of dec 12,1899 midnight! If in original design they haven't done that mistake within same 8 bytes space they could cover a broader range of datetimes and yet still support empty date. The datetime values wouldn't have the drawback of not exactly defining all hours as they have now (.Net,SQL server etc hide that error). An now all developers pay for the bad original design.

In this special case we do not have a chance and I'm with you there. I was trying to point out, though we do it like that, supporting the idea of empty date makes perfect sense.
Cetin