Depends on your application. This is the way we look at SQL Server data ... the data doesn't belong to us, it belongs to our customer. They can do any damn thing they please to their data. If they have some other method of porting data into the database and that particular method puts 1/1/1900 instead of NULLs into date fields, then we *have* to code to be able to handle that situation. Just because *we* wouldn't put 1/1/1900 into that field from our application, doesn't mean that the customer won't do it.

Now, if you're writing an application where you can say that you have full control of the data, then you can stipulate what gets put into the date fields. In that case I'd say yeah, make sure they're always NULL and then you don't have to bother coding for it.

~~Bonnie



>Is there a reason you would not just use a null value?
>
>>Wayne,
>>
>>>>What happens if you really do need to store 1/1/1900 in the table?<
>>
>>Good question ... probably use the time component of the datetime field to further determine whether it's a valid date or not. The time (something other than midnite) would be something you'd have to consciously put into the column.
>>
>>~~Bonnie
>>
>>
>>>
>>>>
>>>>We handle it this way: we leave the data as is in the table, but handle how it's displayed in a custom date control. You *do* still have to write code that checks for that, but you do it only when it's displayed in the UI.
>>>>
>>>>~~Bonnie