15

Tenemos un comportamiento realmente extraño e incoherente con Linq-to-SQL aquí.Linq-to-SQL y rareza DateTime

Nuestra aplicación está instalada en bastantes sitios de clientes, y funciona muy bien en su mayor parte. Una de las consultas en Linq-to-SQL actualiza una tabla y establece una columna DateTime en un nuevo valor.

En todos los casos - incluyendo nuestros sistemas de desarrollo y prueba - esta declaración-LINQ a SQL se traduce en algo a lo largo de las líneas de:

UPDATE dbo.OurTable 
SET WorkTimeStamp = @WTS 
WHERE ID = @ID 

@WTS = '2011-11-04 14:15:25', @ID = 555 

Sin embargo, en el sitio de un cliente, por razones que aren 't claro para nosotros (aún), esta actualización se traduce en:

UPDATE dbo.OurTable 
SET WorkTimeStamp = @WTS 
WHERE ID = @ID 

@WTS = 'Nov 4 2011 02:15:25PM', @ID = 555 

y por alguna razón, entonces falla en SQL Server 2005.

Ahora, los servidores de ese cliente (servidor web y servidor SQL) tienen instaladas las versiones en inglés de EE. UU. De Windows Server 2008; el idioma en SQL Server está configurado en us_english, el formato de fecha está establecido en mdy, la cuenta de usuario que ejecuta la actualización tiene su idioma configurado en English en SQL Server ..... y esa configuración es la misma en otros lugares (por ejemplo, en nuestra infraestructura de servidor de prueba).

Así que mi pregunta realmente es:

  1. ¿Por qué en la tierra hace LINQ to SQL repente crear una representación totalmente diferente de la misma DateTime para enviar a SQL Server? ¿Hay algún control para controlar esto?

  2. ¿Y por qué ADO.NET y la base de datos SQL Server 2005 SP2 no pueden manejar la declaración UPDATE correctamente? Estamos recibiendo un error en nuestro registro que lee:

SqlTypeException - SqlDateTime desbordamiento. Debe estar entre 1/1/1753 12:00:00 AM y 12/31/9999 11:59:59 PM.

parece ser un error de .NET (más que un error de SQL Server) y parece como si .NET no puede realmente interpretar que Nov 4 2011 02:15:25PM como válida DateTime por alguna razón. Al intentar ejecutar la instrucción UPDATE generada en SQL Server Management Studio, nos parece que no puede "forzar" que el error ocurra - la UPDATE felizmente funciona bien .....

Actualización: alguna otra investigación parece indicar Linq- a-SQL se comporta de forma diferente cuando se va en contra de SQL Server 2005 o 2008.

  • con SQL Server 2005 , nuestras fechas llegar a convertirse en: Nov 4 2011 02:15:25PM
  • con SQL Server 2008 , nuestras fechas se convierten en: 2011-11-04 02:15:25PM
+0

Compruebe la configuración de CurrentCulture para las aplicaciones C#/VB.NET. –

+0

@BogdanSahlean: 'CurrentCulture' está establecido en' InvariantCulture' en todos los sistemas –

+0

Estoy de acuerdo en que se trata de un problema de .NET y no de SQL. Probablemente un error en LINQ2SQL olvidando usar la cultura invariante en alguna parte. ¿La configuración de ubicación de Windows coincide? – leppie

Respuesta

3

Creo que es posible que la persiguiendo el problema equivocado.

primero habría que:

  1. Su modelo de base de datos/LINQ to SQL esquema es preciso.
  2. Su lógica de problema para asegurarse de que no hay forma de que el nuevo valor de DateTime esté fuera de rango. En particular, verifique que no puede ser DateTime.MinValue o DateTime.MaxValue.
  3. Que no está realizando ninguna secuencia hasta la fecha de análisis en su aplicación.
  4. Que el servidor SQL   no tiene desencadenantes (particularmente en lugar de activadores , que podrían estar modificando la instrucción de actualización).

Supongo que usted (o su cliente) comienza obteniendo el 'SqlTypeException - SqlDateTime overflow. Debe estar entre 1/1/1753 12:00:00 AM y 12/31/9999 11:59:59 PM 'mensaje de error y al investigar notó la diferencia en la forma en que se muestran las fechas.

No mencionas de dónde viene la información, así que supongo que algo así como SQL profiler.

Sin embargo, el problema de visualización de la fecha puede ser un problema, ya que no debería ser un problema.

con SQL Server 2005, nuestras fechas llegar a convertirse en el 4 noviembre 2011 02:15:25 PM

con SQL Server 2008, las fechas de llegar a convertirse en: 2011-11-04 02:15:25 PM

No estoy seguro de lo que quieres decir con eso. SQL no 'turn' fechas en cadena ya que no almacena las fechas como cadenas, pero la representación interna es un número (algo así como el número de días desde el 1 de enero de 1900).

Si se refiere a las fechas obtener visualizadas como Nov 4 2011 02:15:25 PM, entonces eso depende del programa que muestra la información.

También, como yo lo entiendo, si está utilizando un parámetro DateTime (que LINQ   a   SQL debería hacer si el modelo de base de datos es exacto), entonces la información que se envía desde el cliente al servidor SQL Server es la representación numérica SQL de DateTime. Esto debería evitar cualquier problema de conversión de fecha y hora entre el cliente y el servidor. Cuando mira, por ejemplo, el Analizador de SQL, no le muestra la representación numérica de la fecha, lo que significará muy poco para la mayoría de las personas, pero intenta ser útil y muestra el valor como una cadena.

Lo importante es que si SQL o SQL Profiler logran mostrar un parámetro de fecha y hora como 'Nov 4 2011 02:15:25 PM', entonces sabe que es una fecha válida, y sabe exactamente qué fecha es esa.

Entonces, sospecho que el problema del formato de visualización probablemente sea irrelevante.

Eso deja la pregunta de por qué su cliente recibe el mensaje de error de desbordamiento SqlTypeException - SqlDateTime.

Lo primero que debe hacer es comprobar qué valor de fecha está configurando, lo que debe hacerse en el nivel de la aplicación y no en el servidor SQL Server, ya que no llegaría tan lejos.(Esta es otra razón por la que no creo que esto sea un problema de configuración de SQL.)

Parece que .NET realmente no puede interpretar que el 4 de noviembre de 2011 a las 15:15:25 como fecha y hora válidas por algún motivo

no veo donde .NET sería aún tratando interpretar cadenas como la fecha a menos que tenga algunos DateTime.Parse comandos y si ese es el caso, entonces el problema no tiene nada que ver ni con LINQ o SQL.

+0

(2) DateTime está configurado en algo como 'DateTime.Now.AddMinutes (5)', así que estoy bastante seguro de que no está "fuera de rango" –

+0

. Está diciendo que .NET convierte la fecha en una representación de cadena para usar en consulta de actualización, no es que SQL lo convierte en una cadena. Y, que .NET está emitiendo un formato diferente de cadena de fecha para SQL 2005 sobre 2008, y que SQL 2005 no está entendiendo la consulta porque el formato no parece ser algo que entienda. –

+0

@marc_s Sé que es poco probable, pero ¿hay alguna posibilidad de que DateTime.Now pueda estar fuera de rango, es decir, la fecha de la computadora/servidor es incorrecta? – sgmoore