Si hay un error difícil de rastrear es precisamente el que viene acompañado de esta leyenda: a character to numeric conversion error…
La descripción del error nos dice que en algún momento de la ejecución de la instrucción en turno, sea en un programa, en una consulta en base de datos, en un stored procedure, función, etc., se está intentando hacer una transformación-interpretación de un dato que se identifica como alfanumérico para poder asignarlo a un espacio donde se esperan valores numéricos.
Normalmente cadenas de texto numéricas, es decir, que contienen solo dígitos y/o el separador decimal, así como los valores nulos, son transformados de forma automática, pero en la primera aparición de un caracter distinto a un dígito numérico, los problemas comienzan.
Durante el desarrollo
Cuando el error es en programación, el reporte del error te indica la línea de código donde está ocurriendo. En casos como Java, el propio compilador te avisará de esta posibilidad y te requerirá incluir un bloque try catch, o simplemente no aceptará este tipo de conversión, como Pascal o Basic, obligándote a cambiar ese intercambio de datos.
En otros como PHP o Javascript donde las variables pueden cambiar su naturaleza de forma dinámica, esto no supondrá un problema… de interpretación, pero sí durante la ejecución, ahora lo abordaremos.
Durante la ejecución
Rastrear una falla de conversión durante la ejecución es relativamente más complejo; si bien, el runtime o el intérprete probablemente te proporcione una referencia exacta del número de línea del código fuente donde ocurrió el incidente, el problema no necesariamente tendrá que ser resuelto en código.
¿Por qué?
Si estás utilizando una biblioteca de la cual sólo tienes los componentes binarios, obviamente no podrás corregir el código, y vaya, lo más seguro es que el código no esté mal, más bien, tendrás qué valores estás intercambiando con el componente del framework en turno. Normalmente esto ocurre al invocar una función, un método, al instanciar una clase. Verifica la definición de los parámetros y actua en consecuencia.
Si el error es directamente en el código que tú estás desarrollando, podríamos resumir las acciones correctivas a dos tipos:
- Verificar que la declaración del tipo de dato es consistente al dato que quieres almacenar
- Verificar que el dato que quieres almacenar no ha cambiado de naturaleza desde su creación, o que estás realizando el casting adecuadamente, sea de forma explícita (como con los metodos toInteger, toDecimal) o que la operación de la que son objeto estos datos sí arroje un resultado que sea susceptible de ser transformado a un valor numérico.
Es importante recalcar en este punto, que la ausencia de error en tiempo de ejecución no presupone correctitud, verifica las reglas de conversión de tu plataforma. Algunos lenguajes no detienen su ejecución por un error de conversión, y en lugar de ello, las cadenas no numéricas son transformadas a un cero.
Cuando esto ocurre en la base de datos, normalmente será en una instrucción insert o update. La solución es clara: verifica qué campos de las tablas tienen la naturaleza numérica y qué datos estás enviando. Si los datos enviados son objeto de operaciones antes de ser persistidos, la revisión será la misma que en programación.
Una instrucción Select no está exenta de presentar este problema, normalmente será porque estás realizando operaciones de caracter numérico sobre columnas que no tienen esta definición; estas operaciones incluyen las que se definan en los campos selecionados, las cláusulas en los JOIN y/o las que se hagan en la sección WHERE.
En una interacción entre un programa y la base de datos, particularmente en un Select, es uno de los más laboriosos para encontrar y diagnosticar, porque el error indica el número de línea, pero no qué campo o campos lo provocan.
Este error puede ocurrir en un simple SELECT hacia variables del programa, hacia un registro o una clase.
Si es en un select, para encontrar a los culpables de la conversión identifica si el error es en el select o en el programa. Si es en el select, regresa al párrafo anterior.
Si es en el programa, localiza las variables destino que tienen naturaleza numérica, ejecuta el select que poblará dichos valores y compara datos. En caso de que visualmente no logres identificar el problema, será tiempo de hacerlo por fuerza bruta, es decir, uno a uno. Modifica el programa temporalmente para hacer el select y la asignación a las variables individualmente, es un trabajo laborioso, pero darás con el culpable.
Cuando utilizas un ORM que mapea los datos de tablas hacia tus clases e instancias, y este es el que está propiciando el error, el motivo es claro, aguno de tus campos en BD o en tu clase no concuerdan en naturaleza. Haz las revisiones como si se tratara de un select, revisa la definición de tus campos en la clase y que coincidan con las de tu tabla.
Corolario
Esta crónica ha sido derivada de un incidente que tuve durante unas pruebas de aceptación con usuario. Al realizar la ejecución de un módulo que ya habíamos probado varias veces, nos sorprende con el error de conversion de datos en un select.
Ocurrieron dos eventos:
- En algún momento del tiempo, la definición de un campo en tabla cambió de numérico a alfanumérico, no así el programa, sin embargo, no habíamos tenido el problema ¿qué sucedió entonces? -en las pruebas anteriores, por azares de la informática, esa columna que es de caracter informativo y no se usa para nada en el procesamiento había estado vacía siempre, de tal forma que el valor nulo se trasladaba tal cual al programa.
- Cuando se dio el cambio de tipo de dato en la tabla, quien quiera que lo haya realizado no reparó en verificar qué programas se podrían ver afectados por el mismo. Se debió hacer esta valoración, ajustar la definición de variables en este programa y recompilar. Aprovecho para referirte a la crónica del Alter table donde precisamente hablo de esto. Agregar una columna a tabla – MySQL
Espero que esta crónica te sea de utilidad y facilite tu deambular en la informática.
Deja un comentario