BDE y Firebird

[[Lepe]]

Hasta donde yo sé, no es conveniente usar double precision para importes monetarios en Firebird (y otras BBDD), ya que dichos valores no se guardan con el valor exacto y al rescatarlos tendrás imprecisiones.

Estos problemas sobre todo, llegan al realizar operaciones con los datos de facturas, base imponible + porcentaje iva - porcentaje de retencion = total factura.

Lo mínimo: NUMERIC(10,2) en dialecto 3, ya que se guardan internamente como un Int64 que no tiene problemas.

Saludos

[[felipe88]]

Usa DBExpress...

[rolandoj]

Empezado por Lepe

Hasta donde yo sé, no es conveniente usar double precision para importes monetarios en Firebird (y otras BBDD), ya que dichos valores no se guardan con el valor exacto y al rescatarlos tendrás imprecisiones.

Estos problemas sobre todo, llegan al realizar operaciones con los datos de facturas, base imponible + porcentaje iva - porcentaje de retencion = total factura.

Lo mínimo: NUMERIC(10,2) en dialecto 3, ya que se guardan internamente como un Int64 que no tiene problemas.

Saludos

Hola,

La observación es importante y amerita una explicación:

Como dije antes, la metodología de portabilidad incluye varios aspectos. Uno de ellos es el problema de la precisión de datos numéricos. En general, el código no debería quedar dependiente de la implementación que un motor de Base de Datos haga de los valores numéricos. El mayor o menor esfuerzo que se haga para lograr esto depende de las condiciones de diseño de la aplicación y la proyección en el tiempo de dicho diseño.
El consejo más básico es, por supuesto, reducir el uso de decimales a lo estrictamente necesario.

El caso más sencillo es cuando los valores máximos proyectados no exceden las capacidades de la doble precisión. La clave está en definir lo más homogeneamente los decimales requeridos y efectuar tempranamente redondeos asegurando que los bloques de datos individuales queden consistentes para que a su vez sean consistentes los acumulados calculado a partir de ahí. En otras palabras, confiar los redondeos a la lógica de la aplicación y no a las capacidades del motor.

Por ejemplo, entre los software que he desarrollado con esa metodología está una contabilidad completa, incluyendo cálculos automáticos de depreciación y ajustes por inflación, que actualmente trabaja con Interbase 6 y en 6 años no ha dado problemas de precisión.

El asunto se complica es cuando la aplicación requiere valores numéricos proyectados que exceden la capacidad de la doble precisión. Hay varias alternativas dependiendo de la complejidad; y de hecho, si es mucha. incluso podría ser necesario considerar sacrificar portabilidad.

Se puede escribir mucho más sobre esto; pero ya sería tema de otro hilo

[peccatum]

Empezado por Lepe

Lo mínimo: NUMERIC(10,2) en dialecto 3, ya que se guardan internamente como un Int64 que no tiene problemas.

Hola

Hice caso y cambié varios dominios a numerico con escala ...

Me queda la duda de cual es la mejor forma de pasar parámetros, ya que el "query.paramsByname('precio').asNumeric;" no existe... por ahora estoy usando ".asCurrency" pero no se si es lo más adecuado...

saludos

[akela]

Empezado por peccatum

Hola

Hice caso y cambié varios dominios a numerico con escala ...

Me queda la duda de cual es la mejor forma de pasar parámetros, ya que el "query.paramsByname('precio').asNumeric;" no existe... por ahora estoy usando ".asCurrency" pero no se si es lo más adecuado...

saludos

Si es lo correcto, porque delphi así te maneja el redondeo que se usa abitualmete para el $$ (€)

[[Lepe]]

Si has cambiado los campos en la base de datos, te faltaría hacerlo en Delphi.

doble clic a tu tabla/query y verás los campos, si seleccionas uno, en el Inspector de objetos te dirá arriba del todo "Importe TFloatField" bien, le das a supr quitando el campo y boton derecho add, ahora mira la declaración, te debería decir "Importe TBCDField" (esto dependerá de tus componentes de acceso, BDE, MDO, IBX, FIBPLUS, BCD es Binary Coded Decimal que es el representante de numeric o decimal de la base de datos.

Quizás al usar campos Float en delphi, se tengan imprecisiones al multiplicar/dividir entre campos, porque recordemos que el fallo es inherente al tipo Float o double precision.

Edito: Después puedes usar .AsCurrency, como muy bien apunta akela.

Saludos.