ADO anchura campos numéricos

[gmart1]

Buenas tardes,
estoy comenzando a convertir mis bases de datos DBF a MYSQL. Una vez importadas las tablas en MYSQL me he encontrado con el problema de la anchura de _ numéricos.
Primero probé con la propiedad nPrecision de los objetos Fields, pero para los tipos Int, TinyInt y BigInt siempre devuelven un valor fijo.
Yo necesito el valor entre paréntesis que aparece en la creación de la tabla, por ejemplo Int(5) es un ancho de 5, en cambio nPrecision es 10 y FWADOFieldLen() es 11.

Lo he conseguido solucionar usando el siguiente código :

Code: Select all

oRS := oCon:Execute ( "SHOW CREATE TABLE " + cTabla )
cCreateTabla := oRs:Fields[1]:value

De esta forma en la variable cCreateTabla se guarda una cadena de caracteres con la sentencia SQL que creó la tabla, como ejemplo :

CREATE TABLE `reembols` (
`ID` INT(11) NOT NULL AUTO_INCREMENT,
`SERIE1` VARCHAR(2) NULL DEFAULT NULL COLLATE 'utf8_spanish_ci',
`TALON` BIGINT(20) NULL DEFAULT NULL,
`SERIE2` VARCHAR(3) NULL DEFAULT NULL COLLATE 'utf8_spanish_ci',
`NUMERO` BIGINT(20) NULL DEFAULT NULL,
`CLIENTE` VARCHAR(25) NULL DEFAULT NULL COLLATE 'utf8_spanish_ci',
`FECHA` DATE NULL DEFAULT NULL,
`IMPORTE` DECIMAL(11,2) NULL DEFAULT NULL,
`BANCO1` VARCHAR(8) NULL DEFAULT NULL COLLATE 'utf8_spanish_ci',
`BANCO` TINYINT(2) NULL DEFAULT NULL,
`APUNTE` INT(5) NULL DEFAULT NULL,
`IBAN` VARCHAR(34) NULL DEFAULT NULL COLLATE 'utf8_spanish_ci',
PRIMARY KEY (`ID`)
)

Ya sólo queda buscar el nombre del campo que queramos y sacar el número entre paréntesis.

Expongo esta solución por si le sirve a algún compañero del grupo y por si alguien conoce una forma más sencilla de obtenerlo.

Un saludo.

[Armando]

gmart:

Podrías crear _ numérico como DECIMAL (5,2), de esa forma
siempre sabrás tamaño y cantidad de decimales.

Para tomar en cuenta, MySql siempre guarda el contenido como tipo carácter
y el punto decimal se almacena, por tanto si defines el tamaño como (5,2)
el valor máximo no será 999.99 sino 99.99.

mis 2 centavos.

Saludos

[gmart1]

Muchas gracias Armando,
en mi caso estoy usando la función FW_ADOImportFromDBF para importar los DBF en MYSQL y me he encontrado que las tablas creadas automáticamente tienen campos BigInt, TinyInt, Int y Decimal.
Además no ha respetado el ancho que tenían originalmente en las DBF, intentaré investigar esa función para adaptarla a lo que quiero.

Por lo que me dices si necesito un campo Int(5), al pasarlo a Decimal sería (8,2). Lo tendré en cuenta, aunque con la solución que he encontrado me sirve.

No sé si "SHOW CREATE TABLE" sólo la tiene MySQL, pero es el motor de base de datos que voy a usar y por ahora sigo en la adaptación a MySQL con ADO.

Un saludo.

[nageswaragunupudi]

With DBF, { "fieldname", "N", 6, 2 } uses 8 bytes including "-" sign and decimal. So it can store from -99.99 to 999.99.

In MySql (and many other RDBS), DECIMAL( 5, 2 ) can store -999.99 to 999.99

Integers:
MySQL INT takes only 4 bytes of storage space on the disk, but can contain values from -2147483648 to 2147483647. This is equivalent to Numeric 11,0 in DBF.

If we want to store a number in this range, do we like to waste 11 bytes of space in MySql or just use 4 bytes only. In addition INT is a lot faster than Decimal.

[gmart1]

Muchas gracias Rao,
lo tendré en cuenta para el diseño de mis tablas cuando esté funcionando al 100 por 100 con ADO y MySQL.

Un saludo.