Why doesn't SQL Server automatically up-convert DATE to DATETIME for comparison purposes?

Question

I love the new DATE datatype in SQL Server 2008, but when I compare a DATE field to a DATETIME field on a linked server (SQL 2005, in this case), like this:

DECLARE @MyDate DATE
SET @MyDate = CONVERT(DATE, GETDATE())

SELECT *
  FROM MySQL2005LinkedServer.SomeDB.dbo.SomeTable
 WHERE SomeDatetimeField < @MyDate

I get this error:

OLE DB provider "SQLNCLI10" returned message "Unspecified error".
OLE DB provider "SQLNCLI10" returned message "The scale is invalid.".

"The scale is invalid" is obviously because the Native client is passing the DATE datatype back to the linked server, and since it's SQL 2005, it doesn't know what to do with it. Running this same query against a 2008 server works just fine - SQL Server is able to compare the DATE and DATETIME datatypes without a problem.

Here's my question - is there a reason that the Native Client doesn't automatically convert the DATE value of '2009-11-09' to a DATETIME of '2009-11-09 00:00:00.000' so that the previous version of SQL Server won't choke on it?

Answer 1

You can achieved this by using ALTER SESSION SET NLS_DATE_FORMAT = 'MM/DD/YYYY HH:MI:SS AM'; This is the temproray solution, If yu are working on UNIX then these setting could be done permanently in .profile.

Answer 2

I can only guess that this is because 2009-11-09 00:00:00.000 is not time-zone-neutral and would be cause of more subtle bugs. Please correct me if I'm wrong.

Answer 3

The internal structure for datetime (2005) and date / time / datetime2 datetimeoffset (2008) are very different to each other, and as with other comparisons the data must be placed into the same type when comparing. So the native client would be forced to make such a conversion.

The native client could be generous and do the implicit conversion for you but equally the 'element of least surprise' that the products tend to work to should suggest that throwing a type at SQL 2005 that it does not natively understand should be rejected. There are a number of subtle errors that can slip in from that one for sure.

Same should be true of throwing a datetime2(7) at SQL 2005, do we expect that it will round off the 100ns accuracy back to the 3.33ms or throw and error - I'd prefer the error and make / accept an explicit cast.