Pregunta

Me encanta el nuevo tipo de datos de fecha en SQL Server 2008, pero cuando comparo un campo de fecha a un campo DATETIME en un servidor vinculado (SQL 2005, en este caso), así:

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

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

Me sale este error:

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

"La escala no es válido" es, obviamente, porque el cliente nativo está pasando el tipo de datos se remontan al servidor vinculado, y puesto que es SQL 2005, que no sabe qué hacer con él. La ejecución de esta misma consulta en un servidor 2008 funciona muy bien -. SQL Server es capaz de comparar los tipos de datos DATE y DATETIME sin problemas

Aquí está mi pregunta - ¿hay una razón por la que el cliente nativo no convierte automáticamente el valor de fecha de '2009-11-09' a una fecha y hora de '2009-11-09 00: 00: 00.000' por lo que la versión anterior de SQL Server no se ahogue en él?

¿Fue útil?

Solución

La estructura interna de fecha y hora (2005) y la fecha / hora / datetime2 datetimeoffset (2008) son muy diferentes entre sí, y como con otras comparaciones de los datos debe ser colocado en el mismo tipo cuando se comparan. Por lo que el cliente nativo se vería obligado a hacer una conversión de este tipo.

El cliente nativo podría ser generoso y hacer la conversión implícita para usted, pero igualmente el 'elemento de la menor sorpresa' que los productos tienden a trabajar a debe sugerir que tirar un tipo en SQL 2005 que no forma nativa entendemos debe ser rechazada . Hay una serie de errores sutiles que pueden deslizarse desde que uno seguro.

mismo debería ser cierto de lanzar una datetime2 (7) en SQL 2005, lo que esperamos que va a redondear la precisión de 100ns de nuevo a los 3.33ms o tirar y error - Yo preferiría el error y hacer / aceptar una conversión explícita.

Otros consejos

Sólo puedo suponer que esto se debe 2009-11-09 00:00:00.000 no es el tiempo-zona neutral y sería causa de los errores más sutiles. Por favor, corríjanme si me equivoco.

Puede logrado esto mediante el uso ALTER SESSION SET NLS_DATE_FORMAT = 'MM / DD / AAAA HH: MI: SS AM'; Esta es la solución temproray, yu Si están trabajando en UNIX entonces esta configuración podría hacerse de forma permanente en .profile.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top