OpenOffice, MySQL y el error al insertar datos con ODBC

Me imagino que este truco ya está obsoleto. Desde que me lo encontré, OpenOffice ha cambiado de versión un montón de veces, y lo mismo ocurre con MySQL y ODBC, así que supongo que ya habrá sido corregido. Pero observa, observa, que fue muy gracioso:

Si quieres usar MySQL con OpenOffice posiblemente te has encontrado en Internet un documento en inglés, muy interesante, que se llama "OpenOffice.org 1.0, ODBC, and MySQL 'How-to'"

Bien, pues si sigues esas instrucciones al pie de la letra, te encontrarás con que funciona, realmente funciona. Excepto por un "nimio" detalle:

Desde OpenOffice no podía modificar ninguna base de datos MySQL que contenga números (¿y qué base de datos no los tiene?). En cuanto lo intentaba, y OpenOffice trataba de grabar el registro, me salía un mensaje de error en pantalla que decía, entre otras cosas, algo así:

"Column count doesn't match value count at row1"

Este mensaje de error significaba... que el número de columnas no encaja con el número de datos en la fila 1. Pero... ¿por qué?. Pues era como si el registro estuviera recibiendo más datos de los que esperaba. Pero el problema era aún más sorprendente si se abría en OpenOffice una consulta SQL. Tecleando los comandos a mano, OpenOffice conseguía modificar la base de datos MySQL sin más. Y resultaba aún más curioso si piensas que en el manual "OpenOffice.org 1.0, ODBC, and MySQL 'How-to'" ni siquiera se menciona un fallo tan garrafal.

¿Entonces qué?

Entonces nada. Me acababa de tropezar con un curioso bug que no estaba claro de dónde se encontraba, si en MySQL, en MyODBC o en unixODBC. Pero la naturaleza del bug sí era conocida: resulta que en el idioma castellano (o en el alemán, o en el holandés... ), el símbolo decimal se representa por una coma, pero en inglés se representa por un punto. Eso significa que la traducción española del OpenOffice intentará pasarle al driver MySQL de unixODBC la siguiente cadena de valores:

values ("luis", "cofiño", 3,0000E12, "asturias")

Donde debería transferir:

values ("luis", "cofiño", 3.0000E12, "asturias")

El resultado es que MySQL se confundía por culpa de la coma decimal, y contaba cinco campos donde debería contar solo 4. Por eso el manual no mencionaba el error. Lo escribió un inglés, así que a él le funcionaba bien.

Vale, pero ¿hay alguna solución?

Bueno, supongo que a estas alturas ya estará solucionado, claro. Pero ahora ya no uso MySQL y mis necesidades de aplicaciones de base de datos han caído en picado. Me basta con Tellico y poquito más.

Pero en su momento sí hubo alguna chapuzilla que pude hacer.

Por ejemplo usando la versión inglesa del OpenOffice. Pero eso es una petardez ¿verdad?. Porque te encanta tener los menús en cristiano, confiesalo.

Vale, pues otra opción es ir a "Herramientas", "Opciones", "Configuración de idioma" e "Idioma". Ahí, vas desplegando todos los diálogos y elige "Español" en lugar de "Predeterminado". Ahora puedes cerrar OpenOffice.

Y ahora puedes abrir un terminal y arrancar tu OpenOffice pero de esta forma tan curiosa:

[00:39:05/0][lacofi@moira:~]$ LC_ALL=C soffice

A primera vista, parecerá que nada ha cambiado. Pero si ahora vas a las fuentes de datos e intentas modificar tus bases de datos MySQL comprobarás que no tienes problemas. :-)

Bueno, sí tienes un pequeño problema: no hay teclas muertas, así que has perdido los acentos. Pero aún conservas la eñe. ;-)

¿Qué ha pasado?. Pues que has engañado al OpenOffice de forma parecida a como él engaña a MySQL. Con el prefijo "LC_ALL=C" le estás diciendo al OpenOffice que arranque con el locale por defecto (o sea, inglés). Pero después, OpenOffice se encuentra con que es la versión española, con todos sus ajustes puestos a español, así que funciona como siempre. Pero no del todo: a nivel interno, seguirá considerandose como un programa inglés, con lo que, al comunicarse con MySQL, le pasará los números con "punto decimal", y no "coma decimal".

Un bug muy, muy curioso, ¿no?.