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:

Eso lo leí en IBPhoenix.

Pues creeme que yo también, guardo la esperanza de que alguien tenga una buena solución al respecto y que además la comparta :).

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.

Es lo que hago yo y me funciona perfectamente.

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í :

Código SQL [-]
Diferencia = Redondear(Debe - Haber, 2)

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.

No llega con eso, ya que la ristra de decimales la introduce al realizar operaciones con los campos numéricos.

Un saúdo.

Yo también trato de hacer eso con la UDF que les mostré, pero asi le diga de antemano que guarde redondeado, al caer a la BD esta se "inventa" el resto de decimales, es mas hice una prueba, si voy por el ibexpert y le escribo los datos en dicho campo manualmente y redondeados, me sucede lo mismo (Luego aparecen los demás datos que nunca le he digitado).

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"

En mi caso particular uso Numeric(15,2), tanto para variables en los procedures, como en las tablas.

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.

Creo que ese tipo no debe tener ningún problema con los decimales.

Exacto, se supone que un Numeric(15,2) es como un Double precision, pero ¿Entonces porque a IVAND y a mi nos sucede esto?, incluso IVAND también a dicho que el declara dichos campos como Numeric(15,2). :(

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.

Pueden no, seguro q se debe a eso,
cambiar el dialecto del 1 al 3 y postear aqui los resultados ;) ..

No creo que los tiros vayan por ahi he cambiado el dialecto a 3 y el resultado de la base sique dandome ese dichoso valor .000010898818 , como le hago para dejarlo en los 2 decimales por dios , ademas al cambiar a dialecto 3 algunos querys no funcionan envia mensajes de diferencias de tipos o algo asi:confused:

Bueno, despues de cambiar a Dialecto 3, debes hacer la prueba truncando todos los registros a 2 fraccionarios y despues si haces la prueba, lo del error es porque estas usando otro dialecto y seguramente hay declarado algun tipo de dato que en el dialecto 3 ya no exista o bien ahora se usa de otra manera.

Sonara algo absurdo pero hago un update a el campo en mencion y los ceros siguen ahi el round no redondea a (n) decimales , es trodo un problemas ademas que los querys no funcionan , abria que seguir revisando y ver que cosas cambian con dialect 3

Mi situacion

Por casi 10 años solo habia usado el dialecto 1, pues ahora que estoy trabajando con horas directamente, pues decidi migrar a dialecto 3, la migracion inicial la realice con el gfix, pero he ahi mi primer error, tengo declarados en muchas tablas y procedimientos, campos date que en dialecto 1 guardaban fecha y hora, para solucionar esto pues cree otra base en blanco corrigiendo eso y traslade datos. Con los campos numericos que en su mayoria para valores los tengo declarados como numeric(15,2), pues resulta que en dialecto 1 en el delphi los campos persistentes los reconoce como TFloatField. y ahora en dialecto 3 los reconoce como TIBBCDField. ahi si que casi que lloro tengo mas de 1500 campos que cambiar en toda mi aplicacion para hacerla compatible con dialecto 3. Espero que realmente valga la pena.

Lo que comentas está perfectamente documentado en los muchos libros de Firebird e Interbase.

¿valer la pena? Pues me parece que no mucho.

Primero porque ya estarás acostumbrado a los redondeos e imperfecciones de los floats y ahora los int64 no los tiene, por lo que tus cálculos pueden que salgan distintos a lo que esperas. La mayoría de operaciones matemáticas darán el mismo valor, pero en algunos casos obtendrás valores distintos.

Eso sí, tendrás los campos de fecha como quieres.

He de reconocer que el dialecto 1 con el tiempo perderá soporte en Firebird, pero no sé cuando pasará.

Estarás pensando en hacer una aplicación que modifique los .pas y .dfm ¿verdad?, a mano ni se me ocurriría. Para algunas cosas lo he hecho y la verdad, merece la pena automatizar una parte del proceso. Ni siquiera uso parsers para esa tarea, suele ser más complejo que cargar en un TStringlist el .pas y .dfm y hacer uso de la función Pos :D (sí, lo sé, suena fatal, pero configurar un analizador léxico / sintáctico con todas las peculiaridades del lenguaje más las manías propias... es demasiado para mí).

Saludos y suerte.

Bueno al final termine mi migracion casi 1 mes de trabajo pero ya estoy sobre Firebird 2.1.1 Dialect 3 y solo he encontrado un par de situaciones donde aun estoy investigando.

Primero que todo yo tambien cree hace muchos años mi UDF Redondear jeje, y no he tenido problemas de redondeos desde entonces.

Ahora bien lo que me paso esta vez fue lo siguiente:

Código SQL [-]
  
declare variable porcentaje numeric(15,2);    
declare variable valor numeric(15,2);    
declare  variable nuevo_valor numeric(15,2); 
BEGIN     
     nuevo_valor = valor * (porcentaje / 100);

la situacion es que si lo coloco asi me redondea al entero mas cercano teniendo, pero si declaro la variable porcentaje como numeric(15,4) todo funciona bien.

Hola a todos , un gusto saludarles y desearles anticipadamente feliz navidad, pues bien una pregunta

voy a tener que migraar la base de datos firebird 1.5 de dialect 1 al 3 , veo que ya se han dado muchos casos asi que aqui creo la experiencia sobra asi que necesito sus buenos consejos ... por ejemplo un companero en el foro indica que creo una base en blanco y luego traspaso los valore de una base a la otra fueras tan amable en indicarme conque herramientas ases eso o asesorme en pasar los datos

Gracias a todos por sus buenos comentarios

Nota : El la mi aplicacion tambien hay muchos campos persistentes como han solucionado ese inconveniente
:confused:

IB Expert versión personal (la gratuita), tienes un botón en la barra de herramientas "extract metadata":
- extraes solo los metadatos con la opción de CREATE DATABASE activada (estructura de tablas, SP, Triggers, etc)
- te saldrá una ventana de texto con ese script:

- lo modificas para añadir el dialecto,
- el character set y el collate (que muy posiblemente no los tengas),
- el nombre de la base de datos (para no sobreescribir el archivo
- ten en cuenta los campos de moneda que deberían ser NUMERIC(9,2) (9 como mínimo)
- los campos date, revisa el release notes que tengas o algún libro de migración, ya que DATE no guarda la hora en dialecto 3, para eso tienes TIMESTAMP
- creo que ya está:o

- Ejecutas ese script y creará la nueva base de datos. guarda ese script por si olvidas algo, poder volver a ejecutar ese script con pequeñas modificaciones.
- Registras en IB Expert la nueva Base de datos.

- Cierras la ventana y vuelves a tu base de datos a la misma opción "extract metadata", pero esta vez sólo extraes los registros. Volverá a crear un fichero de texto con todas las inserciones de esos registros.

- tendrás que modificar los datos, por ejemplo, si tenías un campo DATE, en la inserción incluirá la hora, ahora tienes que borrar esa parte si en dialecto 3 es un DATE.

- En esa misma ventana que te muestra todas las inserciones, tienes la posibilidad de cambiar de "conexión a la base de datos" (despliega ese icono que parece el compilar de delphi), eliges la nueva base de datos y ejecutas el script.
- Hecho, todo insertado.

Ten cuidado con mi alzheimer ;)

Saludos

También puedes usar utilidades como ibdatapump
http://www.clevercomponents.com/prod...ibdatapump.asp
Creo que tienen una versión "free".

¡Hola!

Resulta curiosa la frescura con que comentas eso después de 16 meses. :eek: :)

Hace muchos años que llevo conmigo el programa GReplace. Lo utilizo cada vez que me encuentro en la necesidad de hacer cambios masivos dentro de archivos .pas o .dfm. Podría serte de utilidad a ti también.

En cuanto al redondeo, podrías echar un vistazo a un tema que va relacionado: http://www.clubdelphi.com/foros/showthread.php?t=38102

Debido a lo ahí descubierto, por ahora no hago divisiones o multiplicaciones con números fraccionarios (o fraccionables) a nivel de base de datos que requieran un redondeo diferente al convencional (hacia el infinito). En esos casos hago el redondeo en Delphi, empleando la variable GHNumericRounding y la función ghRound de GH Freebrary (mi biblioteca de funciones) antes de enviar el dato al servidor.

Confieso que la manera en que trabaja esa función no es muy elegante, pero me ha resultado efectiva. Quizá después haga una versión más optimizada de la misma como para incorporarla en Firebird a manera de UDF, y con ello poder hacer las multiplicaciones y divisiones a nivel base de datos sin problemas de pérdida o ganancia inesperada de decimales y para convenciones contables de distintos países.

De hecho, el motivo para crear esta función (y la variable de configuración GHNumericRounding) hace ya varios años, fue el reclamo de una empresa que notaba como el importe total de ciertas facturas generadas por una de mis aplicaciones difería de aquel que venía en las órdenes de compra de sus clientes. Estaba utilizando el tipo de redondeo predeterminado de Delphi (imparcial o mejor conocido como Del Banquero), cuando la empresa quería que usara el de aproximación a cero, por algún supuesto reglamento fiscal (si alguien pudiera confirmarme lo que conoce al respecto en las normas mexicanas, se lo agradecería ;)).

Algunos se preguntarán por qué no me apoyé en funciones nativas como Set8087CW, SetRoundMode y RoundTo. En primer lugar porque todavía no existían éstas, y posteriormente por este desconcierto: http://www.clubdelphi.com/foros/show...573#post170573

Saludos.

Al González. :)

Bueno ahi vamos otra vez

A todos los compañeros mil disculpas por molestar pero , hace un tiempo estoy tratando de cambiar el dialect a mi base de datos ahora ya tengo la metadata de la base lista y las insert tambien lo he pasado y todo esta bien los numeric 15(2) ya funcionan como tienen que ser , pero ahora el problema es la aplicacion gracias a AL Gonzales que me indico una herramienta Greplace v2 ya puede cambiar el tipo de dato de Tfloatfield aTIBBCDField o algo asi (si no es el tipo de campo me disculpan estoy fuera de mi trabajo) , pero al querer abrir mi base me indica que un campo se ha definido TfloatField pero es TIBBCDField , el problema se debe a que son campos persistentes y debo borrarlo y volver a insertarlo ahi es donde solo cambia el tipo de precision de 15 a 18 , hay acaso alguna manera de forma masiva hacer ese cambio

Trabajo con delphi 6 y Ibx


Gracias creo que ya estamos casi listos para la migracion definitiva