12 respuestas en este tema

[look]

Amigos tengo esta consulta sql:

SELECT upd.VehId,  upd.GPSTime, upd.Streets, upd.Speed, upd.Bearing, upd.Odometer, veh.Alias, alerts.AlertText, alerts.AlertType 

FROM Vehicles veh, VehicleUpdates upd, PastAlertDetails alerts 

WHERE (upd.VehId=77) AND alerts.AlertAt=upd.GPSTime AND alerts.VehId=upd.VehId 

AND (alerts.AlertType BETWEEN 3 AND 4)  AND veh.VehId=upd.VehId 

AND upd.GPSTime BETWEEN CONVERT(DateTime, '2013-5-21 00:00:00', 120) AND CONVERT(DateTime, '2013-5-21 23:00:00', 120)  

ORDER BY veh.Alias, upd.GPSTime

este es el resultado de la consulta:

http://img23.imagesh...3/875/imavs.png


esta consulta la utiliza un reporte de una aplicacion que tiene un cliente, aqui el reporte:

http://img811.images.../6404/ima2d.png


como pueden observar los datos son los mismos a excepción del campo de fecha, es aqui donde esta mi duda, en la base de datos aparece una fecha y hora y en el reporte aparece otra, no se que es lo que pasa , ¿como es que el reporte saca esa hora en la fecha?. ¿ alguna idea de que puede ser?


Saludos!

[enecumene]

¿Seguro que en ambos casos son las mismas consultas y no una resta entre dos tiempos como la anterior situación (el de las millas)?

Saludos.

[look]

¿Seguro que en ambos casos son las mismas consultas y no una resta entre dos tiempos como la anterior situación (el de las millas)?

Saludos.

si amigo, es la consulta que lanza ese reporte al sql server la extraje monitoriando las consultas, no logro entender porque la hora es distinta en ese reporte y cambe mencionar que es la hora correcta y no la que veo en la base de datos

[look]

si pueden observar en la feha que hay en el sql server y la del reporte hasta los segundo son iguales , solo es la hora que es distinta... 

[luisgutierrezb]

Que tipo de campo es, DateTime? o TimeStamp? a veces el reporteador/sistema operativo hace ajustes por la zona horaria...

[look]

Que tipo de campo es, DateTime? o TimeStamp? a veces el reporteador/sistema operativo hace ajustes por la zona horaria...

es un DateTime, no se que tipo de ajuste hace el reporte pero es la correcta.

[luisgutierrezb]

Entonces revisa que zona horaria tiene la pc donde generas el reporte, a lo mejor el sistema la guarda en UTC, si tienes la zona horaria de UTC menos 6 por ejemplo, (basado que en la consulta la hora es 11 y en el reporte 5) puede ser lo que te de la diferencia...

[look]

Entonces revisa que zona horaria tiene la pc donde generas el reporte, a lo mejor el sistema la guarda en UTC, si tienes la zona horaria de UTC menos 6 por ejemplo, (basado que en la consulta la hora es 11 y en el reporte 5) puede ser lo que te de la diferencia...

en efecto es problema de la zona horaria, se la he cambiado y me ha dado el resultado de la consulta, ahora bien... el correcto es el del reporte por lo que tendre que restarle esas 6 horas de diferencia a las consultas para que muestre la hora real ya que mi zona horaria es bien.

[Delphius]

A ver, yo estoy confundido.
Si dices que desde el reporte sale bien pero consultando en forma directa al SQL Server sale con diferencias de hora entonces el problema está en el lado del servidor. Y no el lado del cliente.

No debieras de hacer una resta de 6 horas en tu aplicación solamente porque resulta ser que, para este caso que se te ha dado, de esta forma "cuadras" resultados.
En todo caso debieras de revisar si en el equipo servidor hay algo que está mal configurado, y/o si en SQL Server está tomando alguna configuración regional o formato de hora en particular.

El punto es que si haces desde el lado cliente tal diferencia de hora entonces ahora si que el reporte (se supone que el reporte es client-sade, o mejor dicho que la aplicación envía al reporteador la consulta) te dará resultados erróneos.

Es eso o yo entendí mal cuando dices:

en efecto es problema de la zona horaria, se la he cambiado y me ha dado el resultado de la consulta, ahora bien... el correcto es el del reporte por lo que tendre que restarle esas 6 horas de diferencia a las consultas para que muestre la hora real ya que mi zona horaria es bien.

Por otro lado ¿A que le has cambiado la zona horaria?

La verdad es que no está claro a que pretendes cambiar la hora y/o a donde piensas hacer tal resta (que a mi ver no es la mejor de las soluciones).

Así como existe DecimalSeparator para establecer el carácter decimal en los formatos de números reales para la aplicación, también existen variables asociadas a la configuración regional sin necesidad de alterar en dicho equipo la configuración regional predeterminada (y convengamos que no es nada bueno que un sistema altere a ésta).

Saludos,

[luisgutierrezb]

Bueno, no creo que sea un problema en si del servidor, bueno si y no, por una simple razón, que yo sepa en MS SQL Server el tipo DateTime NO tiene el concepto de zona horaria por lo que hay que manejarlo de manera "manual", o sea sumar y restar del lado del cliente...

[Delphius]

Bueno, no creo que sea un problema en si del servidor, bueno si y no, por una simple razón, que yo sepa en MS SQL Server el tipo DateTime NO tiene el concepto de zona horaria por lo que hay que manejarlo de manera "manual", o sea sumar y restar del lado del cliente...

A ver si me explico mejor.
Si look comenta de que al ejecutar la consulta para el reporteador y éste le devuelve el resultado correcto, pero si a dicha misma consulta la ejecuta desde el administrador de base de datos, el propio  motor, le presenta resultados diferentes es síntoma de dos posibles cosas:

1. El motor MS SQL Server (que suponemos que está en un equipo destinado a modo servidor) tiene una configuración regional propia o bien ha sido configurado con un formato de presentación de fecha/hora tal que casualmente la diferencia de hora son 6. Esto no quiere decir que almacene mal sino que a efectos de mostrar los datos éstos son formateados. O bien,

2. En el servidor hay una configuración regional no congruente con la que look piensa que debiera esperar y el motor toma a ésta, mientras que el reporteador establece sus propios valores de configuración y casualmente éstos son los adecuados y que espera look.

REPITO: no es problema del tipo de dato*. Simplemente estoy ilustrando que hay un escenario confuso en esto y que el "problema" de algún modo está en el servidor o de una casualidad en los clientes.

* Aunque convengamos que con la adición del tipo "especial" (fuera de lo establecido en el estándar SQL) que ha metido Microsoft con el TIME(P) y TIMESTAMP(P) en la versión 2008 ha traído más problemas que soluciones. Sino búsquese en la red de redes con términos como TIME(7) y vean de lo que digo.

Saludos,

[Wilson]

Está bueno este "chicharrón", como decimos en Colombia, a estos casos confusos.

Coincido con Delphius en que la discordia no está en el motor de la DB (este solo almacena y  devuelve lo que le pidan, en el formato que le pidan), el "problema" tampoco está en el servidor y no deberías tocarlo (puede que a este servidor  tengas la posibilidad de meterle mano y cambiar configuraciones, pero habrá casos en que dicho servidor esté en fuera de tu alcance),es lógico que el detalle está en el  código de acceso que usan  tanto el gestor de reporte como la otra aplicación en cuestión y que una de las dos está relacionada  directamente con la famosa UTC, prueba de esto es que al cambiar la configuración de zona horaria los resultados cambian.

Para solucionar esto no es necesario que cambies ninguna configuración en el servidor, deberías buscar la forma de que tu consulta vaya también ligada al UTC, quizá este o este artículo te arrojen luces de cómo hacerlo.

Un cordial saludo.

[look]

Hola amigos, veran... estube analizando bien el caso y les contare mas sobre el trabajo que estoy haciendo..
bien, esta base de datos es de un sistema de monitoreo de camiones, los gps de los caminoes mandan constantemente la informacion a la base de datos, al lado de estos gps hay una aplicacion que casualmente esta hecha en delphi por la compañia de gps, la cual tiene una serie de reportes como el que les mostre, entonces me han pedido hacerles una aplicacion de reportes basado en esos datos, analizando bien me he dado cuenta que la aplicacion toma en cuenta la zona horaria al momento de consultar los datos en la base de datos ya que en esta se guarda de una manera pero se refleja bien con forme a la zona horaria que  este usando la computadora, como mencione anteriormente he logrado extraer las consultas de esos reportes monitoreando el sql server por lo que puedo ver con detalle el comportamiento de este, ahora bien los gps son los encargados de mandar la informacion a la base de datos  y puede que estos sean los que tienen mal configurado la zona horaria, tendre que investigar con los tecnicos que instalaron los dispositivos para ver si el problema esta en eso.

Saludos!