>Hi Michel,
>
>>

>>        ' Return an empty date
>>        ' expT1 Date
>>        Public Function GetEmptyDate() As Date
>>            Return New Date(1899, 12, 30, 0, 0, 0)
>>        End Function
>>

>
>I wonder, what you would suggest, if someone wants to store the 30th of December 1899 in that datetime field. <s>
>
>The problem is, that, unlike most other databases, VFP date and datetime fields support a blank value and many VFP devlopers unfortunately think that this makes sense. In order to be somehow compatible to the rest of the DB world, I would suggest to avoid blank values in VFP date fields and store a NULL value in that field.

Holger,
Because it makes sense:) Unfortunately it is original implementation of datetime that doesn't make sense. Why would 0 mean dec 30,1899 when it's datetime and empty when it's a numeric datatype. One or the other it's not null but 0.
In most applications you don't care the difference between a null or "" or null and 0.
Say you have a shipDate field which naturally you don't fill in ahead of time when you get an order. Setting it to null seems to be the logical answer when it really is not. You don't know the date yet, right but shipFreight might be 0 or shipWith "" while it doesn't mean you know and forgot to fill in them. How many application would really care the difference of being it null vs empty.
For other datatypes you have the option to have an 'empty' value (and except for applications where difference really matters using null is asking for trouble), but not for a datetime. Doesn't that sound to be nonsense? You put null support to a datetime just to support empty concept. Unfortunately IMHO it's a forced misuse of null by backends + .Net DateTime itself (and we were told it was designed from ground up - this simply sounds to be a backward compatibility).
Cetin