Trabajar con campos Time

[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 Noteví]

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..