Probando, para informar del bug que había detectado el día anterior, me he dado cuenta de que en realidad no es un bug. Resulta que he recordado que a los números de coma flotante no se les puede limitar el número de decimales, ellos deciden cuantos decimales ponen. Tampoco se les puede limitar el tamaño, sino que el tamaño, en realidad, es el número de bites que emplean para representar cada número y esto va implícito en el tipo de datos (FLOAT o DOUBLE).
Aunque, si creas un campo con números en coma flotante, en la tabla se muestra con un decimal, podemos modificar este comportamiento (los decimales que se muestran, no el número real de ellos). En el vídeo de hoy lo muestro. También veremos en el vídeo, con algunos ejemplos, que los dichosos números de coma flotante no son exactos.
Por otro lado, en el vídeo anterior dije que ya sabía que es imposible modificar el tipo de datos en las tablas, y que esto era un bug conocido por mí. Como ocurre muchas veces, y en un solo día hemos visto dos ejemplos, casi siempre que pensamos que algo es un bug, en realidad el bug somos nosotros y nuestro desconocimiento.
Al modificar los tipos de datos, Firebird impide realizar las modificaciones que suponen pérdida de datos y la única solución que propone es eliminar los datos y crear una columna nueva (si no los puede convertir no sabe que hacer con ellos). Sin embargo, permite sin ningún problema modificar los tipos de datos cuando no suponen ninguna pérdida. Por ejemplo, puede convertir un entero (INT) a doble precisión (DOUBLE), pero no al revés, porque, en este segundo caso, ¿qué hace con los decimales?.
Hoy vamos a ver y solucionar el problema que dije que había con el NIF y de paso hablaremos de la conveniencia o no de utilizar índices.
Y comenzaremos con el primer formulario. Con los formularios, si nos da tiempo, veremos que podemos solucionar el problema del desbordamiento de datos (eso que vimos de que cuando no cabe, da la vuelta y comienza por los negativos).
Comentarios
Publicar un comentario