Driver dbExpress para db2 falla al leer valores BCD de campos DECIMAL

[rolandoj]

Hola a todos,

Tengo el siguiente problema.

Mi aplicación maneja valores de 18 dígitos de precisión con 2 decimales (definidos como campos DECIMAL(18,2)).

El driver dbExpress de Delphi 2007 para DB2 graba correctamente en la Base de Datos estos valores (lo verifiqué usando el centro de control de DB2).

Sin embargo, cuando los lee, ignora los dígitos decimales. Por ejemplo, digamos que grabamos el valor 10.08 ; cuando lo lee, lo lee como si fuera 1008.

Por lo dicho antes, es claro que el problema no es de DB2. Ahí le llega bien el 10.08. Tampoco son las rutinas de conversión ya que con Firebird, funciona bien.

Hice depuración y el problema es cuando obtiene el formato nativo BCD.

Ese formato es un registro TBCD el cual tiene 3 campos : Precision, que indica los dígitos significativos; SignSpecialPlaces, que sirve para el signo y la cantidad de decimales; y Fraction, un arreglo de bytes con los valores en sí

Por alguna razón, el campo Fraction llega escalado. En esas circunstancias, dado que no tengo forma de saber cuando hay, o no hay, realmente decimales, no puedo arreglar el problema usando mis propias rutinas de conversión. Así pués no se me ocurre una solución distinta a conseguir otro driver.

Como referencia, estoy con Delphi 2007, el driver dbExpress es dbxdb230.dll, el cliente db2 es db2cli.dll y la versión de db2 es la 9.7.

En cierta forma, ya tengo un driver; es un driver ODBC que viene con DB2; pero, como se usa un driver ODBC en dbExpress ?. No he consguído documentación y en el fondo es el mismo problema que mencioné, para el caso Firebird, en esta otra nota :

http://www.clubdelphi.com/foros/showthread.php?t=68936

Alguién puede orientarme.? Agradezco cualquier ayuda

[rolandoj]

Hola,

Más de 3 semanas y ninguna respuesta. En este punto se me acaba el tiempo y la decisión parece que tendrá que ser desechar db2.

Me parece increíble tener que hechar a la basura semejante motor de base de datos por un problema aparentemente trivial.

Peor si tenemos en cuenta los resultados de mi busqueda en internet y consultas en foros.

Hay montones de mensajes reportando el problema y varias sugerencias; pero, ninguna solución de fondo. De hecho hay reportes indicando que el problema viene desde el principio de dbExpress y supuestamente fué solucionado en la versión 2006 con la introducción del parámetro DecimalSeparator en la configuración del driver; pero, aquí, en Delphi 2007, ese parámetro no está trabajando.

Las sugerencias tampoco han funcionado y al parecer hay dos problemas en lugar de uno :

Por una parte, dbExpress tiene el error de que no está manejando bien el parámetro DecimalSeparator. Por otro lado, db2 parece tener una falla de diseño, ya que no hemos encontrado por ningún lado una forma de configurarle al cliente el separador decimal. Todo indica que no lo soporta.

El enfoque de db2 parece ser que los setting regionales los maneja en bloque, no permite cambiarlos individualmente. En nuestro caso, es un grave problema porque para resolver lo del separador, tocaría usar la versión en Inglés y ahí se nos pierden los caracteres propios del español.

Así pués, repito la pregunta para ver si esta vez alguién puede aportar una solución. Un nuevo driver dbExpress, configurarle a dbExpress un driver ODBC para db2, o alguna forma de cambiarle el separador decimal al cliente db2

[[egostar]]

Hola

Lo que yo creo es que el problema está en el driver de dbExpress y no en la base de datos.

Yo tuve un problema con los decimales utilizando dbexpress solo que en lugar de "quitar" el punto decimal que es tu caso a mi no me mostraba los decimales si estos eran cero.

A ver si esta solución te ayuda antes de que decidas desechar la base de datos.

En el evento GetText de tu campo

Código Delphi [-]

procedure ClientDataSet1CAMPOGetText(Sender: TField;
  var Text: string; DisplayText: Boolean);
begin
  Text := FormatFloat( TFMTBCDField(Sender).DisplayFormat,Sender.AsFloat );
end;

NOTA:

Se debe asignar la propiedad DisplayFormat con el formato que se desea, en mi caso $,0.00, no toma en cuenta la propiedad Currency = True


saludos

[rolandoj]

Hola egostar,

Ante todo, muchísimas gracias por el interés.

Infortunadamente, en mi caso, esa solución no aplica porque el problema no es al momento de desplegar el dato; por tanto, los formateos usuales de Delphi no ayudan. El problema lo tengo en el momento mismo en que el driver recupera el dato desde el cliente db2.

En mi caso, ni siquiera uso el TClientDataSet. El problema ocurre desde la recuperación por parte del query. La misma propiedad AsBCD, que se supone trae el dato nativo, viene equivocada. De hecho, las rutinas de formateo de string, que trabajan a partir de ese dato "nativo", están bien.

Por cierto, hay una observación importante para tú código. Estás usando AsFloat. Los valores de doble precisión manejados por AsFloat funcionan bien; pero, mis campos son TFMTBCDField porque usamos decimal(18,2), que excede la capacidad de los double precision (o sea, no puedo obtener los valores con AsFloat). Desgraciadamente, nosotros necesitamos esa precisión y son muchísimos los campos definidos así.

Concuerdo en que el principal problema es el driver, he investigado, y sospecho que es un error introducido en la versión 2007. Me explico:

Según documentación encontrada en Internet, el error, que viene desde el principio de dbExpress, fué solucionado en la versión 2006 (no la tengo, y no puedo confirmar la veracidad de ese dato).

En la versión 2007, explican que dbExpress fué reescrito y al parecer hay una curiosidad. La versión de dbExpress que viene ahí es la 4; pero, como viene con soporte para la 3, los nombres de los drivers los dejaron con el sufijo 30, que hace pensar que es la vesrión 3.0 .

Lo importante es que si la reescribieron, es probable que hayan cometido un error y por eso el parámetro Decimal Separator haya dejado de trabajar bien.

Los reportes son todos antiguos, así que sospecho que la gente se había aburrido de los diversos problemas que daba la herramienta y cuando arreglaron ya era tarde. Eso parece confirmarlo el que en este foro muy pocos trabajan dbExpress y mucho menos db2. Por eso, es probable que no haya habido presión reciente para corregirlo.

Vale anotar que el problema lo reporté con nuestro distribuidor nacional, este a su vez me dice que lo escaló a la casa matriz; pero, me temo que, si lo arregaln, la solución llegará demasiado tarde para mi.

No sobra mencionar que también concuerdo en que el problema no está en la Base de Datos; pero, creo que si hay también una falla grande de diseño en el cliente db2 como tal, porque ese cliente debería permitir cambiar individualmente los settings regionales (Bueno, al menos yo no he encontrado nada acerca de como cambiarlos)

[[egostar]]

Vaya, pues que mal.

¿ Y no has utilizado otro componente a manera de verificar si realmente es el driver ?, tal ves usando ADO con el OLE Provider de DB2.

Yo me dí cuenta de que mi problema estaba en el driver porque lo comparé con IBX y todo funcionó bien.

Otra cosa que se me ocurre es si puedes cambiar el tipo de dato en DB2 de DECIMAL(18,2) a NUMERIC(18,2)

Digo, a estas alturas cualquier opción vale

saludos

[rolandoj]

Empezado por egostar

Vaya, pues que mal.

¿ Y no has utilizado otro componente a manera de verificar si realmente es el driver ?, tal ves usando ADO con el OLE Provider de DB2.

Yo me dí cuenta de que mi problema estaba en el driver porque lo comparé con IBX y todo funcionó bien.

Otra cosa que se me ocurre es si puedes cambiar el tipo de dato en DB2 de DECIMAL(18,2) a NUMERIC(18,2)

Digo, a estas alturas cualquier opción vale

saludos

Hola,

Gracias por el apoyo.

La verdad no he intentado con ADO. No lo manejo, y aún si funcionara con ADO me sería totalmente inviable migrar la aplicación a ADO. Ahora, si con ADO no funcionara, habría que pensar que la falla es más del cliente db2; pero, a efectos prácticos, sería la misma conclusión; o sea, tener que abandonar db2.

Respecto a cambiar de DECIMAL a NUMERIC; me pareció curioso y traté de cambiar en una tabla existente; pero, el centro de control no me muestra NUMERIC como un tipo de dato. Opté entonces por crear una tabla nueva directamente vía SQL: Ahí si me aceptó poner NUMERIC; pero, al consultar la definición de la tabla me muestra es DECIMAL.

Supongo que en db2. al ser sinónimo, optaron por usar solo la palabra DECIMAL.

Con tiempo prepararía la prueba que sugieres; pero, en vista de estos primeros resultados, creo que no vale la pena. Piensi que para db2, es idéntico; para ellos, la palabra NUMERIC es solo un sinónimo para reconocer sintaxis SQL. LA estructura interna y todas las consultas deben tener estructura única

Por cierto, con Firebird funciona muy bien, y esa sería mi solución. Es el que he usado en desarrollo. La verdad db2 brinda muchas posibilidades interesantes sobre Firebird y por eso lo queríamos para productivo; pero, con este problema ... !!!!!!!!!!!!!!!!!

[[egostar]]

Hola

Recién leo en tu primer post donde comentas que tienes un driver de db2, ADO te permite usarlos desde el ODBC. Si con eso no funciona como lo requieres Yo no invertiría mas tiempo y me voy a Firebird, que a decir verdad no le pide nada a ninguna base de datos.

saludos

[rolandoj]

Empezado por egostar

Hola

Recién leo en tu primer post donde comentas que tienes un driver de db2, ADO te permite usarlos desde el ODBC. Si con eso no funciona como lo requieres Yo no invertiría mas tiempo y me voy a Firebird, que a decir verdad no le pide nada a ninguna base de datos.

saludos

Hola,

La verdad es que terminar usando Firebird parece inevitable. Lo máximo que esperaré será hasta el Lúnes.

Respecto a ADO; como dije, en mi caso no aplica porque es una tecnología que nunca he usado; además la aplicación ya está hecha y es enorme. Sería inviable pensar siquiera en pasarla a ADO.

Lo peor de todo esto es que db2 se presentó como una propuesta clave para la solución final de implementación de los proveedores de hardware y software. El tener que abandonarlo me representa una enorme cantidad de problemas por fuera del tema técnico; especialmente, porque del lado de los proveedores todo ha estado muy bien.

De hecho, de lo poco que he conocido de db2 y de lo que miramos cuando se revisó la propuesta integral (db2 es free; pero, venía como elemento clave en una solución integral que involucra otra serie de elementos de hardware y software), tengo claro que posee características muy interesantes.

[rolandoj]

Hola,

A último minuto funcionó una prueba al azar !!. Es increíble que por un error tan simple estuvieramos a punto de cancelar el uso de DB2.

El caso es que en los archivos de incialización de dbExpress el parámetro Decimal Separator no estaba funcionando; pero, hoy se me ocurrió probar eliminando el espacio en blanco entre Decimal y Separator en el dbxConnections.Ini; y el asunto funcionó !!. dbEXpress entendió que db2 le enviaba los números usando como separador la coma y ya actuó bien.

Bueno, ciertamente habrá que probar a fondo; pero, al menos en las pruebas iniciales que estoy haciendo está trabajando bien.

Es el tipo de cosas que uno dice : Por qué no se me ocurrió antes ?. Bueno, en parte porque el tener parámetros separados por espacio en blanco es normal en los drivers dbExpress, y en parte, si había tenido alguna sospecha en ese sentido, incluso hice una prueba de escribir Decimal_Separator , o sea usando _ como separador entre ellos porque había visto que ponían User_Name y no User Name.

Habrá que ver si lo mismo aplica para otros parámetros, caso DB2 TransIsolation.

Agradezco a todos la ayuda brindada, y ya lo saben: Al menos la línea :

Decimal Separator=,

Debe colocarse como :

DecimalSeparator=,

Cuando tú cliente db2 esté usando coma en lugar de punto.

Es pués un error simple en dbExpress; pero, db2 también tiene su problema porque no pudimos encontrar forma de cambiarle desde afuera el separador decimal.

[[egostar]]

Pues que bueno que ya funcionó y resolviste tu problema y lo más importante es que tu propuesta de negocio ya podrá continuar como lo planeaste.

saludos