views:

50

answers:

2

I have a few SQL Server tables with a datetime field that really only has to contain dates... and the fact that it's a datetime object violates data integrity, because it's possible for data to be inserted with a time - which isn't really valid for this field. The result is that we have to convert it and strip off the time every single time we use it. We've considered adding triggers to make sure that no data can even get in with a time attached... but it seems to me that this should really be part of the database software, and shouldn't need to be specifically programmed each time.

Why doesn't SQL Server have separate date and time data types? Is this going to change in the near future? Do other database platforms have this functionality?

+3  A: 

SQL Server 2008 has DATE and TIME data types.

What version are you using?

Cade Roux
(wow. quick answer.) I think we're still on 2005... was it just added for 2008?
froadie
Yes, this was added in 2008
ZippyV
so... what's the accepted implementation of this if you're still on an older version?
froadie
... upgrade? :)
GalacticCowboy
@GalacticCowboy... I wish :P
froadie
The workaround for 2005 and earlier for date is just ignore the time portion and trim when needed. For time, use a standard date portion like 1/1/1900.
Joel Coehoorn
@froadie Upgrading to new data types even if they were available would still be significant work - if you can change your schema in 2005, add a persisted computed column which removes the time portion and do not use the underlying datetime anywhere. If you have a view layer or stored procedure layer, this is a fairly simple refactoring to stop exposing the underlying datetime to anyone, and you may not even need to change your client application above that layer.
Cade Roux
+1  A: 

SQL Server has a pure date and time data type since version 2008, they also added a bunch of new datetime types, now it also goes all the way back to year 1 instead of 1753

SQLMenace