problemas con tipos de datos
#1
Escrito 11 diciembre 2013 - 09:59
#2
Escrito 11 diciembre 2013 - 10:19
-9,223,372,036,854,775,808 -> 9,223,372,036,854,775,807
#3
Escrito 11 diciembre 2013 - 10:55
Creo que no comprendí la situación...
Saludox !
#4
Escrito 11 diciembre 2013 - 11:17
No comprendo... en tu base de datos tienes un campo que no acepta más que valores entre -263 a 263-1 y quieres guardar el valor 7711030301 que hasta donde veo es mucho mayor que 263-1...
Creo que no comprendí la situación...
Saludox !
Jejeje, no amiguis, el bigint es de
-2^63 (-9.223.372.036.854.775.808) a 2^63-1 (9.223.372.036.854.775.807)
Le falto pues el exponente
Saludos
#5
Escrito 11 diciembre 2013 - 12:06
pero cuando levanto la tabla con ADO en delphi... le asigna el el tipo de dato Largeint ( -2,147,483,648 to 2,147,483,647)... entonces cuando yo le asigno el valor : 7711030301 me tira eerror porq esta fuera de rango... osea q el problema esta en delphi....me xplico?
El valor 7711030301 si se puede guardar en la BD pero delphi no lo permite porq lo toma como entero por el tipo de dato con el que lo levanta el ADO
Alguna ayuda? cambio el tipo de dato en la BD o hay otra manera de trabajarlo en delphi?
#6
Escrito 11 diciembre 2013 - 12:56
saludos.
#7
Escrito 11 diciembre 2013 - 01:03
No comprendo... en tu base de datos tienes un campo que no acepta más que valores entre -263 a 263-1 y quieres guardar el valor 7711030301 que hasta donde veo es mucho mayor que 263-1...
Creo que no comprendí la situación...
Saludox !
Jejeje, no amiguis, el bigint es de
-2^63 (-9.223.372.036.854.775.808) a 2^63-1 (9.223.372.036.854.775.807)
Le falto pues el exponente
Saludos
Ya decía yo
Y si muestras un campo calculado entre tus fields y haces el manejo del valor de manera "manual" ya sea con el INT64 que sugirió poliburro o con string como lo sugiere genriquez ???
Saludox !
#8
Escrito 11 diciembre 2013 - 02:43
Como manejo el int64??
como podria manejarlo manualmente??
El campo no se puede manejar como string
#9
Escrito 13 diciembre 2013 - 03:27
#10
Escrito 13 diciembre 2013 - 08:53
Gracias por responder!
Como manejo el int64??
como podria manejarlo manualmente??
El campo no se puede manejar como string
Las opciones que tienes son las siguientes:
[tt]
TIntegerField; // -2,147,483,648 to 2,147,483,647
TSmallintField; // -32768 to 32767
TWordField; // 0 to 65535
[/tt]
Y como podrás observar ninguna se ajusta a tu requerimiento.
Lo único que te queda (si o si) es usar un campo de tipo float:
[tt] TFloatField; // 5.0 * 10^-324 to 1.7 * 10^308[/tt]
Aunque me parece que deberías de cambiar el tipo también en la base, de otra forma habría una incompatibilidad de tipos.
Saludos
#11
Escrito 16 diciembre 2013 - 04:42
Lo único que te queda (si o si) es usar un campo de tipo float:
[tt] TFloatField; // 5.0 * 10^-324 to 1.7 * 10^308[/tt]
Aunque me parece que deberías de cambiar el tipo también en la base, de otra forma habría una incompatibilidad de tipos.
Saludos
Ojo, un float admite números muy grandes, pero no cualquier número: 1.000.000.000.000 puede ser representado, pero porque solo tiene 1 cifra significativa, si fuese 1.234.567.890.123 que es "igual de grande", la cosa cambia, tienes 13 cifras significativas y eso en un float no "cabe".
Si miras la tabla de delphi con los limites de los diferentes tipos, el real trae unos límites enooormes, pero "significant digits" pone "7-8", es decir, que el número que comento arriba NO PUEDE almacenarse en un float!
No puedes almacenar, por ejemplo, 150 millones uno (150.000.001) porque son 9 cifras significativas... no vale un real, y lo peor, aparenta que sí hasta que te cruces con un "extraño error" que hace que el número almacenado, al recuperarlo, ha cambiado!
Si quieres campos numéricos de verdad y no te vale string ni partir el número en dos partes, solo tienes el int64 por parte de delphi, y por parte de FireBird, tendrías el INT64, es decir, lo tienes en los dos extremos, te falta que tu conexión lo admita... te falla solo la parte del ADO.
#12
Escrito 16 diciembre 2013 - 05:22
#13
Escrito 16 diciembre 2013 - 09:37
Vaya, releyendo veo que es MS Server... en FireBird te salvaría usar tipo Numeric(10,0) que por dentro es un Int64 y sería perfecto porque admite enteros de hasta 10 cifras (NUMERIC admite hasta 18 cifras significativas).
Cierto, no había visto el tipo TLargeintField.
"TLargeintField fields are database fields that contain large (64-bit) integer values."
Saludos
#14
Escrito 16 diciembre 2013 - 06:41
Como la suite de componentes ADO debe amoldarse a diseño del "estándar" ADO no cuenta con capacidad de generar un Field capaz de almacenar el dato. Por ello es que no se verá un .AsInt64 en ADO.
No al menos en las versiones ADO y/o de Delphi que datan de antes del 2005/6; al día de hoy me extrañaría si ADO no haya evolucionado e incorporado el tipo INT64.
Si no está en posibilidad de instalar una nueva versión, se deberá emplear otra suite.
Saludos,
#15
Escrito 16 diciembre 2013 - 10:20
Muchachos, no tengo Delphi a mano para comprobarlo pero apostaría que el problema no es Delphi ni de la base de datos. El culpable es ADO que no tiene soporte para tipos enteros tan grandes.
Como la suite de componentes ADO debe amoldarse a diseño del "estándar" ADO no cuenta con capacidad de generar un Field capaz de almacenar el dato. Por ello es que no se verá un .AsInt64 en ADO.
No al menos en las versiones ADO y/o de Delphi que datan de antes del 2005/6; al día de hoy me extrañaría si ADO no haya evolucionado e incorporado el tipo INT64.
Si no está en posibilidad de instalar una nueva versión, se deberá emplear otra suite.
Saludos,
Con mi TurboDelphi usando un componente ADOtable si se tiene soporte a Int64 a través del campo TLargeInt como lo podemos ver en la unidad DB.
{ TLargeintField } Largeint = Int64; TLargeintField = class(TNumericField) private FMinValue: Largeint; FMaxValue: Largeint; procedure CheckRange(Value, Min, Max: Largeint); :::::
Saludos
Archivos adjuntos
#16
Escrito 17 diciembre 2013 - 07:05
¿De que año es Turbo Delphi amigo?
Muchachos, no tengo Delphi a mano para comprobarlo pero apostaría que el problema no es Delphi ni de la base de datos. El culpable es ADO que no tiene soporte para tipos enteros tan grandes.
Como la suite de componentes ADO debe amoldarse a diseño del "estándar" ADO no cuenta con capacidad de generar un Field capaz de almacenar el dato. Por ello es que no se verá un .AsInt64 en ADO.
No al menos en las versiones ADO y/o de Delphi que datan de antes del 2005/6; al día de hoy me extrañaría si ADO no haya evolucionado e incorporado el tipo INT64.
Si no está en posibilidad de instalar una nueva versión, se deberá emplear otra suite.
Saludos,
Con mi TurboDelphi usando un componente ADOtable si se tiene soporte a Int64 a través del campo TLargeInt como lo podemos ver en la unidad DB.
delphi
{ TLargeintField } Largeint = Int64; TLargeintField = class(TNumericField) private FMinValue: Largeint; FMaxValue: Largeint; procedure CheckRange(Value, Min, Max: Largeint); :::::
Saludos
Por algo he dicho: tengo mis dudas de si alguna versión tanto de ADO como de Delphi anterior al 2006 tiene el soporte hacia Int64.
Si alguien con una versión anterior puede darle una miradita para corroborar mis sospechas
Saludos,
#17
Escrito 17 diciembre 2013 - 07:37
Tengo Delphi 7 y aunque no tengo SqlServer pude verificar que en los componentes ADO si existe el tipo de dato largeint.
Para tener acceso al campo en formato LargeInt, sería con la siguiente instrucción
TLargeintField(Table1.FieldByName('Id')).AsLargeInt := 7711030301;
Saludos.
Archivos adjuntos
#18
Escrito 17 diciembre 2013 - 08:48
Hola
Tengo Delphi 7 y aunque no tengo SqlServer pude verificar que en los componentes ADO si existe el tipo de dato largeint.
Excelente dato. Muchas gracias por compartir amigo
#19
Escrito 17 diciembre 2013 - 09:02
¿De que año es Turbo Delphi amigo?
Por algo he dicho: tengo mis dudas de si alguna versión tanto de ADO como de Delphi anterior al 2006 tiene el soporte hacia Int64.
Si alguien con una versión anterior puede darle una miradita para corroborar mis sospechas
Saludos,
Aunque ya ha contestado Gustavo que si existe en versiones anteriores a D2006, sí, Turbo Delphi es un extracto del RAD Studio 2006 que si recuerdas fué cuando Borland decidió separar los IDE's de su portafolio y creó a CodeGear para la transición.
Saludos
#20
Escrito 17 diciembre 2013 - 10:21
Pues esto me da la pista entonces de que hay algo en ADO, y en la versión de Delphi que está empleando abraham85 que no es capaz de generar el TLargeIntField por defecto como para que se deba recurrir a un cast indirecto.
¿De que año es Turbo Delphi amigo?
Por algo he dicho: tengo mis dudas de si alguna versión tanto de ADO como de Delphi anterior al 2006 tiene el soporte hacia Int64.
Si alguien con una versión anterior puede darle una miradita para corroborar mis sospechas
Saludos,
Aunque ya ha contestado Gustavo que si existe en versiones anteriores a D2006, sí, Turbo Delphi es un extracto del RAD Studio 2006 que si recuerdas fué cuando Borland decidió separar los IDE's de su portafolio y creó a CodeGear para la transición.
Saludos
Repasemos: está empleando SQL 2005, está confirmado que ADO ya en D7 cuenta con el Field para el soporte hacia un INT64. Entonces hay una cuestión de diseño y en como trabaja ADO. La cuestión es ¿que versión de Delphi está empleando abraham85?
El problema no es en si de Delphi, sino en como es que trabaja ADO para ese tipo y en como esto afecta al diseño de la suite que envuelve al estandar. Algo ha cambiado en los últimos años. Porque se pasó de un cast a que efectivamente se pueda leer el dato sin requerir de eso.
Si alguien además de D7 tiene SQL Server 2005 pruebe hacer una tabla con campos INT64, vaya a Delphi y genere los campos persistentes de forma automática (y no manualmente) para esa tabla. Diganme que clase de Field se ha obtenido. Repitan el ejercicio en un entorno ADO + Delphi del año 2006 o más.
Allí está el punto. ¿Se entiende ahora?
Saludos,