![]() |
VALORES FANTASMAS FIREBIRD 2.1 valores Grandes
Buenas Tardes Foristas
Se presento un incidente con la base de datos firebird 2.1 , lo comparto para que tengan cuidado con este error , el cual no genera mensaje de error cuando cambia el valor Table // SE GENERA EL ERROR CON VALORES GRANDES
DEFINIR EL VALOR COMO DOUBLE PRECISION
|
¿Y cuál es el error que se genera?
Por cierto, ¿firebird permite dos puntos en un valor flotante? // Saludos |
¡Huy!, me has dejado sordo con tanto grito ;)
|
Me parece que el error es del que introduce los datos :D
|
Apuesto a que lo escribió desde una de esas modernas tabletas. :D
Ya, en serio, ASAPLTDA. ¿Podrías explicar el problema? :) (De preferencia respirando y con un teclado normal). ;) |
Error en Grabar Datos
el problema es que se graba y firebird no envia ningun mensaje de error, solo recibe el valor y cuando se hace el commit cambia el valor . Por eso envio el comentario a la comunidad ya que los errores silenciosos son los peligrosos :eek:
Ahora el valor que reporto en el sistema es sin separador de miles, he colocado los separadores solo para facilitar la lectura el problema se observo usando delphi 5 / ibexpert base de datos firebird 2.1 ¡Huy!, me has dejado sordo con tanto grito , me disculpo con las persona sensibles al ruido. pero solo se dejo en mayusculas los mensajes de aviso Ahora cuando te pasa algo como eso ya no grito, busco una solución o solicitud ayuda a travez de este foro |
Hombre, para empezar (y no despistarnos) deberías de haber puesto las sentencias sql originales y no con "máscara" ;)
Y lo segundo, y más importante, no es un error, así como lo lees :) Eso te pasa por usar float para esos menesteres. Mejor incluso que double, usa numeric. Haz una búsqueda por los foros, es un tema que se ha tratado en diversas ocasiones. Por cierto, yo también pensaba que era un error que yo fuese tan feo, fui al médico por si era alguna deformidad debido a alguna extraña y desconocida enfermedad. El médico me contestó que no era ningún error, sino que yo era así por naturaleza, feo, feo, feo... Y no por eso voy gritando por ahí ¡¡¡soy un error, soy un error...!!! ;););) Moraleja: que no vayas gritando por ahí que firebird tiene un error muy grave, cuando eso no es un error, es lo normal. |
Hasta donde entiendo, esto no es un error y por eso Firebird no lo reporta. Tiene que ver con la precisión que se especifique para el número flotante.
// Saludos |
Je, je. Me ganó Casimiro por un pelín :)
// Saludos |
Sobre los Campos float
No se cual es alcance para considerar si algo que sucede es un error, y si lo expreso es porque cuando en la vida real uno se le presenta un problema de esos le puedo asegurar que es muy grave y esa es la razon de informar.
Por ejemplo : si en un campo float usas el valor 374031472 firebird recibe el valor pero almacena o retorna 374031478 valor 374000000 firebird recibe el valor pero almacena o retorna 374000000 valor 374031000 firebird recibe el valor pero almacena o retorna 374031008 valor 375000000 firebird recibe el valor pero almacena o retorna 375000000 13835485725 -> 13835486208 Como pueden observar si se ingresa un dato uno espera que se almacene el mismo valor, fuera del conocido problema del manejo de decimales y ya que no es muy frecuente usar cifras en el sistema que soporto. Te todos modos agradesco sus comentarios , pero también hago un critica constructiva a todos las personas para que no traten a otros en una forma poco cordial:( ya que el experto existe por el menor grado de conocimiento de otros |
Cita:
Siento que te hayas molestado, pero todos nos equivocamos, mejor dicho, no podemos saberlo todo. El "problema" con los float los descubrí en 1998, y desde entonces usé siempre double. Sin embargo, estaba tan tranquilo cuando surgió un extraño incidente en ciertos cálculos (que ni recuerdo ahora mismo) y me tuvieron semanas dedicado a resolverlo, hace ahora 3 años, descubrí que (según qué casos) también podía traerme "problemas" los double, así que cambié a numeric(x,y). Y desde entonces se acabaron esos "problemas". Que ya digo, no son problemas de los tipos, sino de no usar los correctos a cada caso. Por ejemplo, para porcentajes puedes usar los float tranquilamente. |
Avanzando en el conocimiento
Apreciado amigo, puedes gritar usando letras mayusculas y minusculas. El grito no esta en los caracteres si no en las expresiones usadas.
Pero reitero mi agradecimiento a todas las personas que respondieron haciendo un esfuerzo grande en buscar la solucion y mas aun en tomarse un tiempo para responder de una forma a otra aportando a la solucion de Mi problema y espero que esto contribuya a la solucion de otro que se enfrente a la misma situacion. |
Mira este hilo, amigo ASAPLTDA, ahí se habla de todo esto, tipos, redondeos, casos reales, etc.
Te aconsejo que lo leas entero. Y disculpa de nuevo si antes fui un poco "bruto" contestando. |
Hay otros hilos muy interesantes que se refieren concretamente a esos tipos de datos en firebird, pero no los encuentro... :(
|
Hola ASAPLTDA. En lo personal creí que tomarías de buena gana los comentarios que tuvimos para tu primer mensaje. Te ofrezco una disculpa si te hice sentir mal, pensé que lo tomarías como algo divertido, gozando del momento chusco que se suscitó, tras recapacitar y darte cuenta de lo precipitado que había sido el mensaje inicial del hilo. Siento que hayas tomado de forma negativa estas libertades propias del compañerismo...:o
Aceptar que una variable o campo de punto flotante (Float, Double, Single, Real, Extended, Real48,...) no siempre guarda el valor exacto que se le da es algo por lo que pasa tarde o temprano casi todo programador. :) Una variable o campo entero tiene dos límites: el valor máximo y el valor mínimo. Puede contener un número entero siempre que ese número se encuentre en el rango que enmarcan dichos límites. Entre más bits tenga la variable o campo para almacenar el valor, mayor será ese rango. Con 32 bits, por ejemplo, la variable puede tener uno de 4294967296 valores posibles. Una variable o campo de punto o coma flotante es otra cosa. Teóricamente puede almacenar cualquier número real, es decir, tanto números enteros (0, -400, 87, 23000), como decimales (0.5, -400.8, 87.6, 23000.9) y con cualquier cantidad de cifras (0.5, -400.8001, 87.783992338, 23000.752). Esto hace que los límites de un flotante no sean simplemente el valor menor y el valor mayor, como en el caso de los enteros, sino la "precisión" o exactitud con que puede guardar un número. Es un hecho que entre más grande sea la variable (Single, Double, Extended) más bits tiene para mejorar esa precisión o exactitud. ¿Cuántos bits necesita tener una variable para poder guardar cualquier número real? Si quieres responder esa pregunta, tendrás que preguntarte primero cuántos números reales existen. ¡Son infinitos! Y por ello ni una variable que ocupara toda la memoria RAM podría guardar a cualquiera de ellos con precisión. :) Ante esto, el estándar que adoptaron los fabricantes de hardware y software hace muchos años fue el de permitir que las variables y campos de tipo flotante sacrifiquen la exactitud de los números que almacenan, a fin de que en la práctica podamos usar estas variables y campos para manejar "cualquier" valor que deseemos, aunque haya de repente una pequeña pérdida o ganancia de decimales. Después de todo, para la gran mayoría de las aplicaciones sólo interesan unas cuantas decimales (generalmente de 2 a 5). Y si son números reales muy grandes sin parte decimal, al no poder ser representados por los bits que tienen estas variables, se sacrifica también una parte de los mismos (por ello la diferencia que viste). Es la naturaleza de los valores de punto / coma flotante. Están diseñados para guardar "cualquier valor", pero esa capacidad tiene un costo, el costo de la precisión, así que en realidad no guardan valores específicos, sino aproximaciones. Internamente, sus bits no representan un sólo dato, como las variables de tipo entero, sino varios datos que son factores de una fórmula. La computadora ejecuta tal fórmula con dichos datos para poder hacer algo con el número. Esto es a grandes rasgos, sin entrar en detalles demasiados técnicos (en parte por falta de conocimiento mía). Si quieres un campo que guarde el valor que tú le des y no una aproximación, no uses campos de tipo flotante como Float o Double. Usa Integer si son enteros o Numeric si han de llevar una parte decimal. Un abrazo flotante. Al. P.D. Esta fue una de mis pésimas explicaciones, pero quizá haya valido la pena. :) |
Hay un artículo extenso , en inglés, que lleva un nombre bien calzado: "Lo que todo informático debe saber sobre aritmética de punto flotante".
Si leyeras ese artículo sabrías el porque de este misterio. Cuando uno va a trabajar con punto flotante debe estar consciente de que se trabaja con cierta precisión y no con exactitud. Por cierto, cuando uno trabaja con el tipo NUMERIC(x,y) en realidad está utilizando una aritmética de punto fijo. Y en términos prácticos Firebird internamente aprovecha los tipos enteros que ofrecen aritmética exacta (siempre y cuando los valores estén en su rango, obviamente) por lo que no hay pérdida alguna. Ahora bien, en aritmética de punto fijo se establece la cantidad de decimales esperados... si los valores con los que se va a trabajar son demasiados grandes o no tienen una cantidad fija o esperada no queda otra que utilizar el tipo double que ofrece una "exactitud" hasta los 15 dígitos. Saludos, |
Agradecimiento al Esfuerzo de los Foristas
Independiente de que algunas lineas hallan exaltado los animos , solo los escrito reflejan el esfuerzo de una comunidad en apoyar a uno de sus integrantes.
agradesco su cooperacion y me disculpo con todos los foristas cuando un comentario mio los incomodo. Gracias foristas por su exfuerzo dedicacion y paciencia |
Cita:
|
La franja horaria es GMT +2. Ahora son las 20:22:35. |
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