Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > MS SQL Server
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 11-01-2013
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.941
Poder: 27
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
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)
__________________
El malabarista.
Responder Con Cita
  #2  
Antiguo 11-01-2013
Avatar de GustavoCruz
GustavoCruz GustavoCruz is offline
Miembro
 
Registrado: jul 2006
Ubicación: Sampués Sucre (Colombia)
Posts: 296
Poder: 21
GustavoCruz Va por buen camino
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

Última edición por Casimiro Noteví fecha: 11-01-2013 a las 21:57:55.
Responder Con Cita
  #3  
Antiguo 11-01-2013
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.941
Poder: 27
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
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.
__________________
El malabarista.
Responder Con Cita
  #4  
Antiguo 11-01-2013
Avatar de GustavoCruz
GustavoCruz GustavoCruz is offline
Miembro
 
Registrado: jul 2006
Ubicación: Sampués Sucre (Colombia)
Posts: 296
Poder: 21
GustavoCruz Va por buen camino
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
Responder Con Cita
  #5  
Antiguo 12-01-2013
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 28
Delphius Va camino a la fama
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.
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #6  
Antiguo 12-01-2013
Avatar de Casimiro Noteví
Casimiro Noteví Casimiro Noteví is offline
Merodeador
 
Registrado: sep 2004
Ubicación: En algún lugar.
Posts: 32.682
Poder: 10
Casimiro Noteví Tiene un aura espectacularCasimiro Noteví Tiene un aura espectacular
Cita:
Empezado por Delphius Ver Mensaje
[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?
Responder Con Cita
  #7  
Antiguo 15-01-2013
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 28
Delphius Va camino a la fama
Cita:
Empezado por Casimiro Notevi Ver Mensaje
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,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
campos memo, autoincremental y time anubis Firebird e Interbase 4 10-02-2008 16:23:22
Interbase/Firebird y campos TIME marcial Conexión con bases de datos 5 16-04-2007 20:03:20
time, comparar 2 campos ttime Pascual Montes Varios 2 29-03-2005 19:50:47
Campos DateTime recibiendo Time amesoft Conexión con bases de datos 1 25-02-2005 22:22:23
campos time/timestamp Giniromero Firebird e Interbase 15 16-12-2003 14:26:23


La franja horaria es GMT +2. Ahora son las 06:43:28.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi