Ya no se que hacer con .0002201010101 de firebird
Hola a todos , estoy trabajando con firebird 1.5 rc4 , tengo una tabla con algunos campos entre ellos debe y haber , para mis diarios debo restar debe-haber y obtener cero , si es cero el estado del diario cambia a 'T=Terminado' , aqui es donde empieza el problemas , los campos debe y haber estan definidos como numeric (15,2) , si vamos al ibexpert y vemos los datos en un lado el del debe se ha grabado un dato como 1.0112219292929 (algunos cosas mas) y el haber como 1 , en otras ocasiones utilizaba cast para restar y el valor era cero pero ahora este valor no es cero el estado no me cambia alguien puede orientarme primero siempre que se ingresa un valor al campo debe nadie lo ingresa con tantos decimales (el campo tiene definido solo dos decimales no esta definido ademas como double precision) , ya no se que hacer me pueden orientar ..... Gracias :mad:
|
Yo he tenido exactamente el mismo problema durante bastante tiempo, he investigado por Internet... pero lo único que he encontrado en alguna parte de ibphoenix, es que el problema es por las operaciones matemáticas que tiene que hacer el procesador y no se que mas rollos, lo triste es que la única solución que sugieren es que los datos se pasen a tipo char o varchar y que desde la aplicación se manejen las conversiones pertinentes...
|
Gracias jhonny por tu interes, que pena que una base tan prometedora tenga estos pequenos y grandes problemas a la vez imaginate esto en un banco seria un desastre .... :-( mis proximos proyectos seran dirigidos a otra base de datos , si la solucion es la que tu propones tendria que cambiar todo el sistema desde sus raices eso significaria muchos años de trabajo
Sabes lo que no entiendo es que de cien lineas que grabo solo una presenta este problemas en el diario especifico Espero exista otra solucion que no sea tan dura de realizar sera que se puede hacer alguna funcion para borrar estos valores o redondear :confused: |
Cita:
Cita:
En cuanto a lo del redondeo pues te cuento que personalmente hice una UDF que lo único que hace, es usar la función RoundTo del mismo Delphi, pero la verdad es que aun asi sigue presentando problemas, sobre todo cuando tengo que hacer sum(debe), sum(haber) y al final sum(dede-haber), eso por ejemplo me puede dar, por el debe 42.12510 y por el haber 42.12410 y el saldo me quedaría 0.01, cuando voy a revisar los documentos descuadrados, la consulta me devuelve NULL, de manera pues que ese 0.01 se produce al sumar todos esos fraccionarios que se "inventa" el FireBird. Ojala este equivocado y exista una solución real a este problema :( |
Ahora si que estamos fritos , como le dices aun contador que el ingreso y te lo muestra 1-1 y el asiento no cuadra que duro , que pena que ese problemas aun bases de escritorios lo tienen bien controlados y no esta potente base de datos , pero hay que seguir ... Gracias por tu tiempo cualquier cosa espero avisarte o que me avises
|
Si no necesitas más de 2 decimales, entonces puedes guardar los datos redondeados a esos 2 decimales.
|
Cita:
Creé una UDF a la que le pasa un valor y el número de decimales a los que quieres que redondee. Para tu caso la cosa quedaría así :
No tendrías que modificar ningún tipo de campo, sólo introducir la función en los cálculos criticos. Un saúdo. |
creo que la solucion está en guardar el debe y el haber ya redondeados a 2 decimales, no redodndear la diferencia.
Es decir Diferencia = debe - haber previamente : debe = redondeo(Debe,2) haber = redondeo(Haber,2) La diferencia nunca puede tener más de dos decimales si previamente el debe y el haber tienen 2 decomales. |
Cita:
Un saúdo. |
Cita:
|
Me uno a lo de Jhonny aunque los guardes como los guardes es mas si haces una funcion en deplhi que sume debe-haber este arroja cero , pero el proceso de cuadre del diario esta en un SP , la base se "Inventa" esa manada de numeros raros ...... Trabajando juntos seguro encontramos una buena solucion o abra que manipular los fuentes ?:eek:
|
Para mi esto nunca fué un problema. Tanto a la hora de guardar como de leer lo hago siempre aplicando la función Redondear que comenté anteriormente. La utilizo en varias aplicaciones, entre ellas un gestor de imovilizado y una aplicación de contabilidad y nunca tuve problemas con los descuadres.
Un saúdo. |
Seguramente el problema viene porque en algún momento trates los datos con alguna variable o tipo de campo "float"
|
Cita:
|
Cuento "mi historia": empecé a usar interbase 5 en 1998, luego interbase 6 (que era libre), luego firebird 1, firebird 1.5 y todavía no hemos pasado a nuestros clientes a firebird 2, pero pronto será.
Pues bien, desde hace ya casi 10 años, todos los valores numéricos, importes, cálculos, etc. lo guardamos siempre como tipo "double". Si son valores monetarios entonces lo guardamos redondeados a 2 decimales (desde que tenemos el euro). Nunca hemos tenido esos problemas de decimales, tan sólo nos puede ocurrir si guardamos valores como float. Cita:
|
Cita:
|
Que tal si leemos el siguiente articulo, http://www.ibphoenix.com/main.nfs?a=...ibp_data_types especialmente donde hablan de
How do I work with money ? |
A ver, no soy muy bueno para el ingles pero esta tablita explica que el problema de precisión que estamos viendo en este momento se debe a que la BD debe estar en dialecto 1 o ¿Me equivoco?
http://www.firebirdsql.org/index.php?op=faq#q0000.dat |
Mi inglés es peor, pero parece ser que numeric(xx,x) en dialecto 3 es un entero de 64 bits y en dialecto 1 es un double precision.
Pueden venir los "tiros" por ahí. Yo siempre he usado y sigo usando dialecto 1. |
Cita:
cambiar el dialecto del 1 al 3 y postear aqui los resultados ;) .. |
La franja horaria es GMT +2. Ahora son las 14:19:27. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi