Trabajar con campos Time

[GustavoCruz]

Hola a todos amigos foreros, estoy utilizando el SQL Server 2008 y delphi 2010 conectando con los componentes ado.

El problema es que me genera un error a la hora de querer mostrar los datos de este tipo en particular.

el mensaje que me muestra es: "Error: la operacion en varios pasos genero errores.". aunque ya ví el hilo que trata sobre el asunto del error no tiene nada que ver con mi problema.

Alguna forma de trabajar con los campos de tipo TIME

Gracias por vuestra ayuda y colaboración

[TiammatMX]

Empezado por GustavoCruz

... "Error: la operacion en varios pasos genero errores.". aunque ya ví el hilo que trata sobre el asunto del error no tiene nada que ver con mi problema.

Alguna forma de trabajar con los campos de tipo TIME...

Pues yo trabajo los datos de hora (Time) como enteros, calculados desde las 00:00 del día. Es decir, 660 para tí, 11:00 am para mí. También tu error puede depender mucho de cómo definiste la columna, si como DATE, si como DATETIME o como TIMESTAMP, lo cual le genera a M$ $QL$erver () muchos conflictos de conversión.

Ojalá te sirva un poco el consejo...

[GustavoCruz]

Hola tiammat gracias por tu pronta respuesta, y cómo sería ese proceso de convertir los datos de enteros a "time".

Gracia de antemano...

[Neftali [Germán.Estévez]]

Tal vez tendrías que ser un poco más concreto con lo que estás haciendo. Tal vez algo de código que estás usando ayudaría. De esa forma podríamos ver si hay algo raro.
Yo también he trabajado con ADO/SQLServer y no he tenido problemas.

Cuando hablas de "a la hora de querer mostrar los datos de este tipo", te refieres a un DBGrid, a un DBEdit,... ¿?¿??¿?

[TiammatMX]

Empezado por GustavoCruz

Hola tiammat gracias por tu pronta respuesta, y cómo sería ese proceso de convertir los datos de enteros a "time".

Gracia de antemano...

Pues así, invertir el proceso de conversión. Si multiplicaste, divides y así..., obviamente hacerlo en una función que puedas llamar para tus reportes, rejillas, campos editables, etc...

[mamcx]

Estas *seguro* que el problema es el tipo de datos? No veo porque razon deberia. Aunque hay veces que ciertos tipos de datos pueden causar pequeños problemas, son casi siempre debido a que no se entiende su uso correcto.

Seria bueno que aislaras la causa concreta del error, por ejm, creando una copia de la tabla que tiene el lio, concentandote a ella, cambiando el tipo de datos, etc... hasta dar exactamente con la causa del error. Tambien quizas probar con otro driver (a sql server hay como 3 formas de conectarse http://www.connectionstrings.com/sql...der-for-ole-db)

[GustavoCruz]

Hola mamcx, estoy plenamente seguro que es el campo.

Utilizo los componentes ado para la conección,
SQL Server me permite el tipo de dato Time(7) pero delphi o los componentes o no sé qué cosa es la que me está generando el problema
intenté el tipo de dato DateTime y por un momento creí que había solucionado el problema pero al momento de visulizar un reporte me manda un error por ejemplo "01/01/190006:44op,m" is not a valid floating point value.

para la conección utilizo la siguiente cadena:

Código SQL [-]
Provider=SQLNCLI10.1;
Integrated Security=SSPI;
Persist Security Info=False;
User ID="";
Initial Catalog=IPSSALUDSOCIAL;
Data Source=ANDERSON\SQLEXPRESS;
Use Procedure for Prepare=1;
Auto Translate=True;
Packet Size=4096;
Workstation ID=PROGRAMADOR;
Initial File Name="";
Use Encryption for Data=False;
Tag with column collation when possible=False;
MARS Connection=False;
DataTypeCompatibility=0;
Trust Server Certificate=False;

quizás se pueda hacer algo.

Gracias de antemano por toda vuestra ayuda

[mamcx]

Si es al momento de visualizar el reporte, el problema no esta en ADO sino en el reporte (supongo). Por la cadena que muestra, el valor es un datetime correcto pero el reporte espera que sea un float.

[GustavoCruz]

Exacto, pero y entonces el campo de tipo Time(7). Qué? se puede o no se puede trabajar con eso y si nó, cómo puedo solucionar el problema del respote. Tengo el FastReport.

Gracias a todos

[[Delphius]]

En la prehistoria usé SQL Server así que lo que trae la versión 2008 ni idea. Pero por lo que leo desde el sitio de MSDN el problema está en el tipo de dato y su precisión.
Resulta ser que los geniesitos de Microsoft ahora han declaro al tipo TIME con la posibilidad de indicar su precisión por debajo del segundo, cuyo valor va de 0 a 7; siendo 7 el valor por defecto.

[OFF-TOPIC]Que yo sepa, esto está fuera de estándar SQL. ¿Que no era que había cierta reglamentación de lo que es un TIME? [/OFF-TOPIC]

Esto hace que dependiendo de la precisión establecida el tipo TIME se enmascare en un formato de coma flotante para el caso. Esto hace que luego al intentar leer el dato no se pueda interpretarlo... a este nivel el problema ya puede ser de/los componentes de acceso que no tienen soporte (actualizado) para SQL Server 2008 y por tanto no saben como trabajar con este tipo de dato.
Justamente en dicho enlace se da la información necesaria de como ofrecer compatibilidad hacia atrás dependiendo del método de conexión.

[Casimiro Notevi]

Empezado por Delphius

[OFF-TOPIC]Que yo sepa, esto está fuera de estándar SQL. ¿Que no era que había cierta reglamentación de lo que es un TIME? [/OFF-TOPIC]

Esta gente de microsoft y sus estándares, si no me gusta... lo cambio o lo invento. Y que los demás se las apañen o que lo traten como estandar, que para eso somos "microsoft", el más grande.
¡¡¡Huy!!!, que ya hace tiempo que no son los más grandes, ¿se habrán enterado?

[[Delphius]]

Empezado por Casimiro Notevi

Esta gente de microsoft y sus estándares, si no me gusta... lo cambio o lo invento. Y que los demás se las apañen o que lo traten como estandar, que para eso somos "microsoft", el más grande.
¡¡¡Huy!!!, que ya hace tiempo que no son los más grandes, ¿se habrán enterado?

Lo raro es que intenté averiguar algo sobre los últimos cambios y actualizaciones al estándar SQL. La última de la que yo me he enterado fue en el 2008 (y como ya estamos en el 2013 no me extrañaría que hubiera alguna más actual). Pero no he visto algo que me aclare que efectivamente sobre TIME(x), TIMESTAMP2 y otros tipos "nuevos" que tiene el SQL Server.

En el enlace que he puesto aclara que es Transact-SQL y como tal es es una extensión al SQL estándar de Microsoft. Y para asegurarme intenté buscar algo sobre TIME(7) y TIMESTAMP2 con Oracle y Firebird (que son los dos motores más fieles al estándar) y no hay nada.

O es que esto de los tipos es un tema que se está revisando para la nueva actualización al estándar y Microsoft ya se está adelantando... Porque si bien Microsoft tiende a ser sus mocosofts, creería que no sería tan loco de poner sus tipos así como así sin ofrecer alguna posibilidad de portabilidad para con los otros motores. Ya que si bien cada fabricante puede extender el SQL, si hay algo en donde no se puede tocar libremente, es justamente en los tipos... Condición necesaria para que se garantice el estándar y se puedan entender entre todos.

Saludos,

[mamcx]

No entiendo la queja. Todos los motores "extienden" el sql e implementaciones a diestra y siniestra, tanto en tipos de datos, comandos, lenguajes internos de programacion, librerias de acceso, etc. Y tambien es comun tener tipos de datos "exoticos".

Manejando varios motores, trabajo rutinariamente con sql server, postgres, mysql, fox, acces, sybase, sqlite, firebird -de los cuales me gustan sql server, postgres para lo "grande" y firebird, sqlite para lo "pequeño" siempre he entendido que lo del estandar sql es como el codigo de los piratas: Mas una guia que una norma..

[[Delphius]]

Mamx el estándar está para respetarlo y no para pasárselos por los huevos.
Parte de que sea estándar está pensado y hecho para que exista una manera homogénea de trabajar y garantizar de que dos motores diferentes puedan tener compatibilidad entre uno y otro si se desea cambiarlos.
Justamente en donde NO SE PUEDE TOCAR TAN LIBREMENTE es en los tipos. Podés no dar soporte completo, por falta de tiempo o algunos detalles técnicos... como por el ejemplo el caso del BOOLEAN en Firebird, pero no podés inventar tipos.
En donde si tienen "libertad" de expandir es justamente en la parte procedural, donde cada motor lo lleva de acuerdo a sus diseños. Pero en lo que es el corazón del SQL: el DDL como el DML está bien definido y los motores deben ser lo más respetuosos.
Por ello no se que pensar, si es que Microsoft ha hecho otra de sus mocosoft con este cambio de lo que es y se entiende por el tipo TIME (1) o si es un intento de tirar más hacia su lado alguna propuesta de las suyas para lo que debiera ser su estándar (que no sería la primera vez).
Un motor no puede estar haciendo esas cosas sin ofrecer algo mínimo de compatibilidad con el resto de los motores. Todo está en el estándar... y por algo está. El propio estándar define en que se quedan muditos y en que cosas pueden ir a sus anchas.
Te aviso además que de los motores que has citado el MS SQL Server es que menos se acerca al estándar. En el otro extremo, están Oracle y Firebird. Oracle, Firebird y MySQL junto a PostgreSQL son los que mejor y más propuestas han llevado a armonizar las cosas. Un buen caso lo puedes ver en el término SECUENCE, una propuesta en conjunta de Firebird y Oracle ya oficialmente aceptada desde el 2008 y ahora todos deben aceptarlo, les guste o no.

(1) Que vuelvo a decir... esto está regulado. Es un dato primitivo y esencial... no estamos hablando de un BLOB que permite ciertas libertades (que así lo ha dejado en claro el estándar).

Saludos,

[[Al González]]

Empezado por mamcx

librerias

bibliotecas

Empezado por Delphius

procedural

procedimental

Y sí, cada fabricante está en la libertad de agregar lo que le venga en gana. Pero hay que ser honestos y notar cómo al que menos le ha interesado ser compatible con los demás (porque en todos ve un "tenebroso fantasma" de competencia) es a Microsoft. Esa actitud es lo que está hundiendo lentamente a la compañía de Redmond.

Mi recomendación para Gustavo (sin conocer lo que sucede en su código) es que, si no hay impedimentos de gran peso, cambie el campo a un tipo de dato estándar, como TimeStamp.

Saludos.

[[Al González]]

Empezado por mamcx

librerias

bibliotecas

Empezado por Delphius

procedural

procedimental

Y sí, cada fabricante está en la libertad de agregar lo que le venga en gana. Pero hay que ser honestos y notar cómo al que menos le ha interesado ser compatible con los demás (porque en todos ve un "tenebroso fantasma" de competencia) es a Microsoft. Esa actitud es lo que está hundiendo lentamente a la compañía de Redmond.

Mi recomendación para Gustavo (sin conocer lo que sucede en su código) es que, si no hay impedimentos de gran peso, cambie el campo a un tipo de dato estándar, como TimeStamp.

Saludos.

Agrego: En Firebird, para guardar una hora sin fecha, usaría el tipo Time, seguro de que no habría problema alguno. Pero en MS SQL Server debe uno andarse con cuidado al elegir el tipo de dato adecuado.

[[Delphius]]

Empezado por Al González

bibliotecas


procedimental

Jeje, no me puedo acostumbrar a esa palabra todavía. Vamos término a término... al menos ya digo Bibliotecas

Empezado por Al González

Mi recomendación para Gustavo (sin conocer lo que sucede en su código) es que, si no hay impedimentos de gran peso, cambie el campo a un tipo de dato estándar, como TimeStamp.
Saludos.

TIME es también estándar amigo. Lo es desde hace un buen tiempo. El tema es que ahora Microsoft en su tipo TIME(p) ha tocado el formato interno y resulta ser que los componentes, controladores, etc no pueden interpretarlo... al menos hasta que salga una nueva versión.
Otra posibilidad es revertir este TIME(p) por alguna de las opciones que se detallan en el enlace que puse unos mensajes antes. Aunque esto no exime a Mocosoft de su culpa... si pones un TIME(p) debes atenerte a las consecuencias y ver el modo de que el resto de los motores y demás herramientas tenga la posibilidad de entenderlo.

En mi búsqueda sobre TIME(7) me he percatado que ha traído más problemas que soluciones. Hay un montón de sitios que se quejan de que desde la incorporación de este tipo especial tienen dificultades para leer los datos. Asi que no es algo propio de Delphi el problemita... es de Mocosoft.

Saludos,

[Casimiro Notevi]

Empezado por Al González

Esa actitud es lo que está hundiendo lentamente a la compañía de Redmond.

Desgraciadamente para ello, es una de las causas.

[GustavoCruz]

Hola amigos del foro,

Con todo esto, cómo es que SQL Server existe, si es que para Mocosoft el tipo de dato TIME apenas hasta ahora para ellos existe y además de esto con tantos inconvenientes.

Bueno en resumen Delphi aún no tiene los componentes que puedan interpretar el tipo de datos TIME(p) de Microsoft, la posibilidad que vi fue utilizar el tipo DATETIME.

Ahora cuando pongo un TDatetimepicker en el formulario y cambio su propiedad Kind a dtkTime por ejemplo hoy "22/01/2013", ingreso la hora que me aparece en el campo de tipo DATETIME, cuando visualizo la tabla en una dbgrid me aparece esto: "22/01/2013 09:52:00 a.m", lo pero del caso es que si inserto más información en la tabla, supongamos que dentro de tres días, me aparecerá "22/01/2013 y la hora que haya insertado".

Mi pregunta, cómo se hace para truncar solamente la hora del campo tipo DATETIME a fin de que en la grilla me aparezca solamente la hora y nada más.

He probado la sugerencia que me hace Al González. me sigue generando error...

Mil gracias de antemano por toda vuestra ayuda

[[Al González]]

La presentación en pantalla la arreglas con la conocida propiedad DisplayFormat, pero aún así, un campo de tipo TimeStamp te estará guardando fecha y hora (no solamente hora). Claro está que si te aseguras de que la parte entera de ese campo sea siempre 0 (1899-12-30) en todos los registros, sería como guardar "solo" la hora.

Mi sugerencia de usar ese tipo es por lo que comentaba Delphius, acerca de que Microsoft decidió cambiar el formato interno del tipo Time. Pero vamos, quiero pensar que todavía puedes usar el tipo Time (como debe ser cuando sólo se quiere guardar horas y no fechas).

Rectificando, creo que debes ir a la verdadera raíz del problema. Echa un vistazo a este otro hilo: http://clubdelphi.com/foros/showthread.php?t=30026

Sinceramente no soy muy partidario de trabajar con MS SQL Server y ADO, dadas las cuestionables características que Microsoft le ha ido agregando a ambas tecnologías (con el principal afán de vender) y los retrasos y situaciones inesperadas que luego causan esas "grandes" ideas. Desafortunadamente, para conectarse a MS SQL Server desde Delphi, me parece que ADO sigue siendo una de las opciones más viables , así que toca aguantarse y encontrar la causa verdadera de cada situación extraña que surge.

Espero te sirva el enlace que puse.

Saludos.