Recuerdo instantes de mi pasado donde he tenido la necesidad de llevar Bases de Datos MDB, Microsoft Access, a bases de datos MySQL.
Recuerdo por entonces MySQL Migration Toolkit, una herramienta para realizar esta carga requerida. No obstante no era de mi agrado, y lo que buscaba por entonces era simplemente obtener un script SQL con el código DDL y DML necesario para el CREATE de los objetos de la base de datos y los INSERTs de los datos. A esa utilidad, hoy Linuxeando, le encontré el nombre: mdbtools.
MDBtools es un suite de herramientas (mdb-array mdb-header mdb-parsecsv mdb-schema mdb-tables mdb-export mdb-hexdump mdb-prop mdb-sql mdb-ver) que permiten, entre sus funciones, obtener esquema de una base de datos y exportar en SQL los datos de la misma.
La respuesta al título de esta publicación es muy sencilla, conectarse a MySQL desde C se realiza mediante una API provista por el mismo proveedor de base de datos.
La API de C es ditribuida con MySQL, no es más que una librería (libmysqlclient) que interfacea entre el programa y la base de datos.
La documentación provista por MySQL es muy completa (MySQL C API), no obstante, fiel a nuestra costumbre iremos a un ejemplo sencillo y concreto.
Oracle SQL Developer es una herramienta gratuita para desarrolladores disponible para Windows, Mac y Linux que permite manipular bases de datos Oracle y de terceros, como DB2, Access o MySQL por medio de un driver JDBC.
La última versión disponible de este cliente es la 2.1 y puede descargarse gratuitamente, previo registro aquí. Para ver la lista de características de la aplicación puedes hacer clic aquí.
Esta publicación tiene origen a partir de una consulta realizada por un compañero. Es usual que esta pregunta se la hagan aquellos que vienen con conocimientos adquiridos en Access, aunque en este caso se trataba de reescribir para SQL Server una consulta originalmente escrita en MySQL (IF en vez de IIF).
Luego de buscar un poco llegué a unas FAQs que dieron solución a este problema.
Te guste o no, las consultas que utilicen IIF (o IF en MySQL) deberán ser reescritas utilizando la expresión CASE.
Hace un tiempo habíamos instalado en Ubuntu la última versión estable de MySQL, MySQL 5.1. La instalación había sido manual (no utilizamos ningún tipo de gestor de paquetes, solo descargamos los binarios en un tar.gz) y seguimos los pasos de instalación para cualquier sistema operativo UNIX compatible.
Hoy haremos el camino inverso, es decir, desinstalaremos la base de datos y como suele ocurrir, desarmar es mucho más fácil que armar, y como verán aquí, la desinstalación no escapa de la regla.
Más de una vez tuve la necesidad de en una consulta enumerar las filas de la misma, por medio de una columna calculada auto incremental ¿se entiende cual era me requerimiento?
Explicándolo de nuevo, mi necesidad era de contar con una nueva columna que sea un número auto incremental y que represente el número de fila. Según el artículo original esto se puede hacer en Oracle a través de la variable rownum (no doy fe de ello pues no conozco).
Bien, en esta publicación disponemos de la solución.
Conocida la adquisición de Sun por parte de Oracle son muchos los rumores, comentarios y deducciones que se generaron en toda la comunidad. Lo cierto es que nadie sabe con certeza que será del futuro de MySQL con esta gran adquisición, pero por las dudas ya se abrieron varios paraguas.
Haciendo un poco de historia, el principio de un final podría iniciarce en enero de 2008, cuando MySQL AB, la compañía detrás de MySQL se convierte en subsidiaria de Sun, a su vez última adquirida en abril de 2009 por Oracle.
Michael Widenius, uno de los propietarios de MySQL AB, luego de la primer adquisición mencionada forma Monty Program AB y sigue trabajando en una rama independiente de MySQL (MariaDB).
Michel, se asusta más cuando Oracle adquiere Sun y creo Open Database Alliace con el objetivo de continuar en forma controlada y/o concentrada el desarrollo de MySQL. Con esto, evitar que la popular base de datos termine desapareciendo y diseminada en un sin-numero de forks de la misma.


Lo que leeremos ahora es una solución bastante artesanal para tracear consultas SQL. Cuando leia mis feeds y leí el título de Cómo “tracear” consultas SQL entré inmediatamente debido a que desconocía un método para realizar esta tarea. Lo que suele suceder es que aveces queremos resolver los problemas de una forma prolija y elegante y lo cierto es que la solución puede ser bastante más rudimentaria pero muy ingeniosa.
Muchas veces suele ser tarea común la de consultar en MySQL el slow query log o verificar en tiempo real con un show processlist cual es esa consulta que está volviendo lento al servidor. Conocida la consulta, ¿como se cual es la aplicación que utiliza dicha consulta?. A menos que conozcamos muy bien nuestro sistema, debemos empezar a buscar en nuestros archivos y hacer algunos que otros grep recursivos hasta encontrar con la aplicación culpable de esa consulta lenta.
Los pasos para configurar la replicación de MySQL no eran muy complicados, ¿recuerdas Configurar replicación en MySQL?
Ahora si quisieramos que la replicación se haga en varios servidores. Básicamente la historia es la misma en cuanto a la creación de usuarios y los seteos para el log binario.
¿Qué cambia? ¿Que debo agregar? ¿Que recaudos debo tomar?
En alguna ocasión ya hemos hablado de realizar backups de MySQL en Linux o cualquier otro clon de UNIX utilizando mysqldump y un pequeño shell script que se ejecute por el cron.
Ahora ¿si debemos hacer lo mismo pero en Windows?
Básicamente el proceso es el mismo, general un script (en Windows escribiremos un .bat) y configuraremos la ejecución del mismo en el Programador de Tareas.