![]() |
Problema con Decimales de Double Precision
Hola a TODOS, foreros/as
Tengo un problema y no se a que puede ser debido. Estoy trabajando con una base de datos en FIREBIRD 1.5.1 y cuando concateno un campo double precision con otro por ejemplo (187.00||Eur) el resultado es el siguiente 187.00000000000 Eur. Solo me pasa cuando el campo Double Precision acaba en x,00. Tal vez sepan como arreglar esto. Gracias desde ya. |
Hola.
Si lo que quieres es que solo salgan dos decimales, convierte antes de double precision a un numerico con 2 decimales. cast(187.0 as numeric(15,2)) || 'Eur' Saludos. |
el mismo problema
yo tengo el mismo problema y al probar el cast me da el erro de identificador
indefinido si agrego la unidad Variants, no puede compilar la aplicacion |
La instrucción publicada por marcos es válida para el dialecto SQL de firebird/interbase, y no para delphi.
Si queres obtener 2 decimales en delphi, habrá que ver si es de forma visual en algún componente, o sobre que tipo de dato. Saludos. |
lo que nesecito es que el importe de una factura al guardarlo en la tabla, uso ib7 y el campo 'importe' es double precision, tenga solo dos decimales, en la pantalla de la aplicacion se ven dos decimales, pero al guardar el dato lo almacena con 8 o 9 decimales, Por ej. un importe 8.80 es guardado 8.800000008934. Como debo hacer para que almacene solo dos decimales
|
La representación de un número dentro de la base de datos, es binaria. Si buscas, verás que no hay forma de representar un número con solo dos decimales en este formato. De alli, que regularmente los números "arrastran" algunos decimales (muy poco significativos) sobre el número que en realidad queremos almacenar.
Esto ocurre en todas las bases de datos, pero algunas (como oracle) ocultan esto del usuario, formateando el número, cuando usas un tipo numeric(10,2), por ejemplo, pero siempre es un efecto visual. He visto que con interbase esto no sucedia, y dado que regularmente uso double precision, no se si sigue comportandose de esta manera el nuevo interbase o firebird, o si ya "maquillan" este pequeño detalle. Este es un "issue" de la computación en general, y cualquier programa que maneje datos numéricos (excel, por ejemplo), se enfrenta a este problema. Muchos sistemas, en aras de ser mas exactos, lo que hacen es almacenar números que de antemano se sabe que almacenaran pocos decimales, en datos enteros (por ejemplo Int64 (bigint)). Luego, aplican la división pertinente. Es una forma de enfrentar el problema. De hecho, firebird/interbase, lo hace para números cuya precisión definida lo permite. Te recomiendo no usar tipos de coma flotante, si no queres toparte con esto. Usa mejor tipos numeric(x,y), donde dejas esto al motor, y si la versión actual de tu base de datos no lo maquilla... seguro en el futuro lo hará. Hasta luego. ;) |
Saludos
Compartiendo el problema de todos. Ya hace algún tiempo tenía ese problema, cuando definía seguro numeric(5,2) retiro numeric(5,2) otro numeric(5,2) Son numeros leidos de una tabla seguro 2.89 retiro 10.0 otro 2.89 en firebird seguro 2.8888899999999 ó 2.88888888899999 ó 2.88999999 o algo así retiro 10.00 otro 2.89 después cambié todos a numeric(15,2) en firebird seguro 2.89 retiro 10.00 otro 2.89 y no he tenido más problema Juan Carlos |
Gracias a todos con el tipo de dato numeric(15,2) solucione mi problema
de nuevo muchas gracias a todos |
Cita:
seguro 2.889999999999999999 o seguro 2.890000000000000001234 Dado que el número es lo mas aproximado posible a su valor real. Saludos. ;) |
La franja horaria es GMT +2. Ahora son las 02:04:43. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi