19 respuestas en este tema

[abraham85]

Buenas gente...tengo un problema con delphi y sql server... saben que tengo mi tabla en sql server 2005  y defini unos de los campos como "bigint" (rango de valores -263 a 263-1 ) pero en el ADO... cuando agrego los fiels en delphi... me toma el campo como Largint ( -2,147,483,648 to 2,147,483,647) el cual es mucho mas pequeño q el yo quiero guardar... entonces cuando intento hacer el post me dice que el numero q intento ingresar , por ejemplo : 7711030301 me dice q no es un entero valido... nose como hacer el camibo en delphi para q me tome un rango de valores mas alto..nose si se entendio mi problema... otra idea es modificar en sql server  y poner el campo a float para q delphi lo tome como float...alguna sugerencia ? saludos!

[poliburro]

Podrías usar el tipo Int64.

-9,223,372,036,854,775,808 -> 9,223,372,036,854,775,807

[Fenareth]

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 !

[egostar]

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

[abraham85]

Hola! el tema es que yo tengo mi tabla en Sql server 2005... tengo mi campo idmarca q es un bigint (-2^63 (-9.223.372.036.854.775.808) a 2^63-1 (9.223.372.036.854.775.807))
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?

[genriquez]

Pregunta?  Tiene que ser numérico?  un código puede ser string, si no haces cálculos matemáticos con ellos o que no tengan miles de millones de registros.

saludos.

[Fenareth]

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 !

[abraham85]

Gracias por responder!

Como manejo el int64??
como podria manejarlo manualmente??

El campo no se puede manejar como string 

[Sergio]

Si ADO no admite campos de tipo Int64 en sus tablas, lo tienes complicado, tendrías que quitar ese campo de la tabla y acceder a el por otro método, pero no te puedo decir mucho más porque no conozco el ADO y no sé si te da algún otro método de acceder a ese campo.

[egostar]

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

[Sergio]

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.

[Sergio]

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

[egostar]

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

[Delphius]

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,

[egostar]

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

Archivos adjuntos

•  4394_a8d9f3f80fe6ca929f6cd6a6a37cc78bdbf5294e.png   193,91KB   6 descargas

[Delphius]

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

¿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,

[genriquez]

Hola

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

•  4396_1f00127b82bfdaabcf4195c30d74837cf24e2fb5.png   105,39KB   5 descargas

[poliburro]

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

[egostar]

¿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

[Delphius]

¿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

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