Activar el motor FEDERATED en MySQL

El motor FEDERATED de MySQL, aunque no es muy versátil, puede resultar útil, por ejemplo, para conectarnos directamente a una tabla en otro servidor MySQL sin necesidad de un intermediario, como un script PHP que copie/verifique/vea datos de otro servidor.

El motor FEDERATED no esta habilitado por defecto en instalaciones estándares sobre Linux, no hay que compilar nada, solo agregarle el parametro --federated en el archivo /etc/init/mysql.conf:

#Busquen esta linea en el archivo /etc/init/mysql.conf
exec /usr/sbin/mysqld --federated

Luego de reiniciar el servicio mysql, verán los resultados:

ivancp@ubuntu$ sudo service mysql restart

 

Para ver que motores están disponibles ejecuten SHOW ENGINES en la linea de comando MySQL:

mysql> show engines;
+------------+---------+-----------+--------------+------+------------+
| Engine     | Support | Comment   | Transactions | XA   | Savepoints |
+------------+---------+-----------+--------------+------+------------+
| InnoDB     | YES     | Supports t| YES          | YES  | YES        |
| MRG_MYISAM | YES     | Collection| NO           | NO   | NO         |
| BLACKHOLE  | YES     | /dev/null | NO           | NO   | NO         |
| CSV        | YES     | CSV storag| NO           | NO   | NO         |
| MEMORY     | YES     | Hash based| NO           | NO   | NO         |
| FEDERATED  | YES     | Federated | NO           | MO   | NO         |
| ARCHIVE    | YES     | Archive st| NO           | NO   | NO         |
| MyISAM     | DEFAULT | Default en| NO           | NO   | NO         |
+------------+---------+-----------+--------------+------+------------+
8 rows in set (0.00 sec)

 

Para conectarnos a una tabla remota y consultar que datos contiene, tenemos que crear la tabla, debe ser muy similar a la tabla remota, pueden ayudarse con el comando SHOW CREATE TABLE para ahorrar tiempo y agregar el parámetro CONNECTION al final.

-- Tabla con conexion a una base de datos remota
CREATE TABLE tabla_remota
(
    id     INT NOT NULL AUTO_INCREMENT,
    campo1  VARCHAR(32),
    campo2  INT,
    PRIMARY KEY  (id),
    INDEX campo1 (campo1)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8
CONNECTION='mysql://usuario:contraseña@1952.168.6.5/base_datos/tabla';

 

Recomendaciones:

  • El único problema es que la consulta puede demorar un poco mas de lo debido, así es que traten de no hacer consultas cuyos resultados sean realmente grandes.
  • Es una pena que aun no esté disponible la posibilidad de conectarse a otros gestores de datos como PostgreSQL o SQL Server, eso sí que sería útil.
  • Deben crear un usuario sin contraseña en la base de datos de destino, para evitar poner la contraseña en la conexión, ya que es fácil de averiguar (con SHOW CREATE TABLE).
  • Las conexiones son permitidas incluso hacia servidores MySQL mas antiguos.
  • Leer la documentación para mas detalles:
    http://dev.mysql.com/doc/refman/5.1/en/federated-storage-engine.html
  • Pueden ayudarse con un Stored Procedure para crear estas tablas FEDERATED.

Espero les sirva.

Simplificar el acceso a MySQL CLI

¿No les ha dado pereza escribir, en la linea de comando, todo lo necesario para conectarse a un servidor MySQL?

Puede que tome menos de un minuto, pero algunas veces un minuto es vital (sobre todo si estamos cerca del fin del mundo).

ubuntu@ubuntu$ mysql -u root -p -h mysqlhost [base_datos]

 

Cuando uno esta apurado, estos comandos suelen fallar varias veces por minuto.

La solución: podemos ayudarnos creando atajos con alias en el archivo ~/.bashrc:

#archivo ~/.bashrc

#comando "my" para conectarse a un servidor local
alias my="mysql -u root -p"

#comando "my2" para conectarse a un servidor remoto
alias my2="mysql -u root -p  -h 192.168.1.56"

 

La proxima vez que queramos acceder al servidor local solo tendremos que escribir en la linea de comando my [base_datos], solamente nos pedirá el password del servidor.

Podemos ser mas osados y dejar el password en el mismo comando alias:

#archivo ~/.bashrc

#comando "my" para conectarse a un servidor local
alias my="mysql -u root --password=tupwd"

#comando "my2" para conectarse a un servidor remoto
alias my2="mysql -u root --password=tuotropwd  -h 192.168.1.56"

 

Pueden usar los acronimos que prefieran, para mi my y my2 son cortos y útiles.

Cada vez que quiero una linea de comando MySQL sólo tengo que cargar una nueva terminal (Super + T), escribir «my mi_base» y [enter]!

Ahora se presenta otro problema, como saber en que servidor me encuentro?

El acceso puede ser super veloz con los accesos directos via alias, pero todas las terminales tienen el mismo prompt por defecto: mysql> y no hay muchas luces a primera vista para saber en que conexión estamos. Para evitar desastres (por ejemplo ejecutar DROP en el lugar equivocado) podemos cambiar el prompt de la linea de comando de MySQL con la opcion --prompt, entonces, nuestra configuración finalmente quedará así:

#archivo ~/.bashrc mejorado

#comando 'my' para conectarse a un servidor local
alias my='mysql -u root --password=tupwd --prompt="local> "'

#comando "my2" para conectarse a un servidor remoto
alias my2='mysql -u root --password=tuotropwd  -h 192.168.1.56 --prompt="server 1> "'

 

Espero les sirva!

Simulando secuencias en MySQL

Quienes hemos usado PostgresSQL solemos fastidiarnos con el código que hay que escribir para tener un campo auto-numérico, pero también hemos llegado a extrañar esa característica cuando usamos MySQL.

Como sabemos MySQL, usa la propiedad AUTO_INCREMENT para campos numéricos que usamos en claves primarias.

Pero en que situaciones podemos necesitar una secuencia? pues les doy algunas ideas:

  • Cuando queremos tener mas de un campo auto-numérico en una tabla.
  • Cuando necesitamos un contador general que podemos utilizar en mas de una tabla.
  • No se me ocurren mas, pero estoy seguro que en algún momento podemos darle un uso.

Manos a la obra:

Necesitaremos una tabla para guardar el valor actual de la secuencia:

create table _sequence
(
	seq_name varchar(50) not null primary key,
	seq_val int unsigned not null
);

Vamos a necesitar también una función para obtener el valor siguiente de la secuencia, incluyendo casos como:

  • Si no existe la secuencia, crearla (para qué complicarnos).
  • Actualizar el nuevo valor para la siguiente llamada
  •  

    He aquí la función getNextSeq que recibe como parámetro, el nombre de la secuencia:

    /*Funcion que devuelve el siguiente valor de una secuencia*/
    delimiter //
    drop function if exists getNextSeq//
     
    create function getNextSeq(sSeqName varchar(50)) returns int unsigned
    begin
        declare nLast_val int;
    
        set nLast_val =  (select seq_val 
                              from _sequence 
                              where seq_name = sSeqName);
        if nLast_val is null then
            set nLast_val = 1;
            insert into _sequence (seq_name,seq_val) 
            values (sSeqName,nLast_Val);
        else
            set nLast_val = nLast_val + 1;
            update _sequence set seq_val = nLast_val 
            where seq_name = sSeqName;
        end if;
    
        return nLast_val;
    end//
     
    delimiter ;

     

    Ahora necesitamos (a manera de mantenimiento) un procedimiento para modificar el valor de una secuencia:

    /*Procedimiento que crea/establece el valor de una secuencia*/
    delimiter //
    drop procedure if exists sp_setSeqVal//
    
    create procedure sp_setSeqVal(sSeqName varchar(50), nVal int unsigned)
    begin
        if (select count(*) from _sequence where seq_name = sSeqName) = 0 then
            insert into _sequence (seq_name,seq_val) 
            values (sSeqName,nVal);
        else
            update _sequence set seq_val = nVal 
            where seq_name = sSeqName;
        end if;
    end//
    
    delimiter ;
    

     

    Es todo!, ahora sólo necesitamos hacer algunas pruebas, para ello vamos a crear una tabla en la cual vamos a tener dos campos auto-generados con nuestra secuencia.

    create table multiple_autonums
    (
       id int not null primary key auto_increment,
       seq_1 int, -- Secuencia 1
       seq_2 int, -- Secuencia 2
       unique(seq_1),
       unique(seq_2)
    );

    Para que la magia ocurra debemos crear también un trigger antes de insertar:

    /*trigger ejecutado antes de insertar que obtiene
      los siguientes valores de las secuencias*/
    
    delimiter //
    drop trigger if exists multiple_autonums_ai//
    
    create trigger multiple_autonums_bi before insert on multiple_autonums
    for each row
    begin
       set new.seq_1 = getNextSeq("seq_1");
       set new.seq_2 = getNextSeq("seq_2");
    end//
    
    delimiter ;
    

     

    Hagamos algunas pruebas

    -- insertando valores para ver que pasa.
    insert into multiple_autonums (id) values (null),(null),(null);
    
    -- Resultado de la primera inserción
    select * from multiple_autonums;
    +----+-------+-------+
    | id | seq_1 | seq_2 |
    +----+-------+-------+
    |  1 |     1 |     1 |
    |  2 |     2 |     2 |
    |  3 |     3 |     3 |
    +----+-------+-------+
    3 rows in set (0.00 sec)
    
    -- Modificando las secuencias
    call sp_setSeqVal("seq_1",47);
    call sp_setSeqVal("seq_2",9786);
    
    -- Insertando nuevamente los valores
    insert into multiple_autonums (id) values (null),(null),(null);
    
    -- Viendo que ha pasado
    select * from multiple_autonums;
    +----+-------+-------+
    | id | seq_1 | seq_2 |
    +----+-------+-------+
    |  1 |     1 |     1 |
    |  2 |     2 |     2 |
    |  3 |     3 |     3 |
    |  4 |    48 |  9787 |
    |  5 |    49 |  9788 |
    |  6 |    50 |  9789 |
    +----+-------+-------+
    

     

    Que les pareció?

    Me acabo de dar cuenta que hay algunas condiciones que no he tomado en cuenta, pero de todas formas sirve. Incluso pueden modificar las funciones para hacer mas complejo el calculo del valor siguiente, se me ocurre por ejemplo que podemos generar numeros de facturas al estilo: [serie]-[numero] ejem: 001-00485

    Espero les sirva.

¿Cuando es necesario comprar una licencia MySQL?

Como seguramente saben, MySQL provee licenciamiento dual, puedes obtener el código fuente bajo la licencia GPL v2 o puedes comprar una licencia comercial.

Hace algunos meses he oído (y también leído) algunos comentarios fuera de lugar sobre el licenciamiento o sobre en que situación es necesario comprar una licencia comercial de MySQL. Escuché por ejemplo que puedes usar MySQL en todo lo que te sea útil excepto para ganar dinero, en nuestro entorno (latinoamericano) es natural llegar a esa conclusión pero NO ES CORRECTA!

Entonces, ¿cuando es necesario comprar una licencia comercial de MySQL? En realidad es muy simple: cuando quieres hacer algo con MySQL que la licencia GPL no lo permita.

Si bien el asunto de las licencias y demás documentos legales los debería interpretar un abogado, (y debería considerar hacer una investigación legal por su propia cuenta) la mala interpretación de la licencia GPL es generalizada y creo que debería tratar de contrarrestar la desinformación al respecto.

Tenga en cuenta que en este artículo voy a utilizar la palabra «libre» con mucho cuidado (en inglés uno de los sinónimos de «free» es gratis), como el usado por la Free Software Foundation. Si usted no sabe qué es el software libre es hora de leer un poco y aprender.

He aquí algunas cosas que están permitidas bajo la licencia GPL:

  • La licencia GPL le permite manejar un negocio con fines de lucro usando MySQL.
  • La licencia GPL permite modificar el código fuente de MySQL en la forma que desee.
  • La licencia GPL le permite vender y distribuir MySQL.
  • La licencia GPL le permite redistribuir las modificaciones de MySQL.

Y usted no tiene que pedirle permiso a nadie, ni pagarle a nadie por el derecho a hacer esto. ¿sorprendido?

Lo anterior viene con algunas restricciones, pero esas restricciones (en general) son sólo para evitar que el software siga siendo «libre». Así, por ejemplo, si usted vende o redistribuye, hay que hacerlo bajo la licencia GPL también. No se puede despojar a la parte GPL o gravar el software y luego pasar a una versión menos libre del software para los demás.

Aquí hay algunas cosas que la licencia GPL no requiere:

  • La licencia GPL no le obliga a redistribuir las modificaciones de MySQL.
  • La licencia GPL no requiere de una licencia GPL del software que simplemente se conecta a MySQL.
  • La licencia GPL no requiere que todo el software en su empresa/organización también sea GPL.

Entonces si usted requiere comprar una licencia comercial de MySQL para las cosas que la licencia GPL no le permite, ¿cuáles son esas?

  • Es necesaria una licencia comercial si desea modificar MySQL y redistribuir el resultado como software no libre.
  • Es necesaria una licencia comercial si desea incorporar MySQL dentro de un programa no-Libre. Tenga en cuenta que incorporar no es lo mismo que «hacer una conexión».

Ya que estas cosas no están permitidas por la licencia GPL, lo que necesita es comprar el derecho de usar el código fuente de MySQL bajo una licencia no-GPL. Ahí es donde las licencias duales entran en juego

MySQL es muy cuidadoso en sus materiales de marketing. Hasta el momento no recuerdo haber escuchado a alguien de MySQL decir que tienen que comprar una licencia comercial para algún propósito específico. Alguna vez leí algo como «MySQL Enterprise es para personas que quieren hacer dinero con MySQL.» Este mensaje de marketing puede ser poco claro para una persona que no conoce a las libertades garantizadas por la licencia de software libre (es decir, puede dejar la falsa impresión de que tienen que pagar por MySQL, si quieren usarlo para obtener un beneficio económico). Sin embargo, estas personas siempre pueden saber la verdad gastando pocos minutos leyendo acerca de las libertades garantizadas por la GPL.

Los casos mencionados arriba sólo es una muestra pequeña. Para ver ejemplos demostrativos y texto que le ayudará a aclarar las ideas sobre la licencia GPL, usted debe leer las preguntas frecuentes GPL.

Referencias:

  • http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.es.html
  • http://www.gnu.org/philosophy/selling.es.html
  • http://www.mysql.com/about/legal/
  • http://www.xaprb.com/blog/

MySQL: show table status mejorado

Desde la línea de comando ciertamente tenemos el control absoluto (siempre y cuando tengamos los privilegios) pero no siempre tenemos una visión general. En este caso cuando estamos logueados a una base de datos MySQL lo primero que solemos intentar averiguar es la lista de tablas y talvez la lista de funciones y procedimientos almacenados de una base de datos.

Este proceso suele ser doloroso por que en cuanto ejecutamos show table status; nos devuelve unas lineas que hasta da pereza interpretar. Lo que devuelve ese comando contiene varias columnas que vistas desde una herramienta visual como MySQL Workbench tienen mucho sentido, sin embargo desde la linea de comando no tanto. Pueden ver en la siguiente imagen como se ve un resultado en una ventana estándar de 80×25:

Para ver el detalle completo podemos agrandar la ventana y disminuir la fuente, pero suele tomar un poco de tiempo hacer eso, realmente es fastidioso.

Es por eso que hace mucho desarrollé un script para mostrar solo lo que necesito incluyendo a los procedimientos almacenados y funciones, recién esta semana que tengo  varias horas de ocio y puedo compartirla con ustedes.

El resultado de mi script es mucho mas comprensible:

Éste es código fuente del procedimiento almacenado:

DELIMITER $$

CREATE PROCEDURE `tools`.`sp_status`(dbname varchar(50))
BEGIN 

-- Obteniendo informacion de las tablas
SELECT
 TABLE_NAME as `Table Name`, 
 ENGINE as `Engine`,
 TABLE_ROWS as `Rows`,
 CONCAT(
    (FORMAT((DATA_LENGTH + INDEX_LENGTH) / POWER(1024,2),2))
    , ' Mb')
   as `Size`,
 TABLE_COLLATION as `Collation`
FROM information_schema.TABLES
WHERE TABLES.TABLE_SCHEMA = dbname; 

-- Obteniendo las funciones y procedimientos
SELECT ROUTINE_NAME as `Routine Name`, 
 ROUTINE_TYPE as `Type`,
 DATABASE_COLLATION as `Collation`
FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA = dbname
ORDER BY ROUTINES.ROUTINE_TYPE, ROUTINES.ROUTINE_NAME;
END$$

Para invocarlo pueden escribir:

mysql> call tools.sp_status(database());

Notarán que he creado el procedimiento dentro de la base de datos tools, esto para que puedan llamarlo desde cualquier parte. Lamentablemente dentro de los procedimientos almacenados no es posible determinar la base de datos actual, es por eso que necesita de un parámetro con el nombre de la base de datos.

He publicado el procedimento en MySQL custom show table status

Espero que les sea de mucha utilidad (como a mi).

`

Una vista a MySQL Workbench 5.2 – SQL Editor

Workbench About DialogNota previa: Esta no es una review minuciosa, es mas bien un tibio comentario sobre mi experiencia de usuario en las ultimas semanas con la herramienta MySQL Workbench 5.2.31 sobre Ubuntu 10.10.

Mi trabajo con MySQL aun no ha llegado al nivel de complejidad que quisiera, ya que tambien trabajo con SQL Server,  es propicia la ocasión para compartiles mis apreciaciones, respecto al Editor SQL (que antes fue MySQL Query Browser).

Si bien estoy muy acostumbrado a la linea de comando, éste no me permite guardar/recuperar un historial de consultas o advertirme de algún «horror», incluso ahora prefiero la linea de comando por que me cuesta menos «clicks» y pulsaciones del teclado. Pero cuando las cosas se ponen serias, o mas complejas, una herramienta como Workbenck se hace completamente necesaria.

Puedo resaltar las siguientes características que me agradan (o no tanto) y paso a comentarlas:

Workbench history tabEl Historial de consultas.
Definitivamente el historial de consultas es muy útil cuando realizas decenas -hasta cientos- de consultas por día. Sobre todo si alguna vez se han preguntado ¿por qué se ha estropeado esta tabla?
El historial recuerda casi todo lo que uno ejecuta, pero no recuerda la hora de ejecución, característica que espero que agreguen pronto.

Workbenck SQL EditorComandos SQL listos!
Todos sabemos que el lenguaje SQL  es muy difícil de escribir, pero algunas veces se hace tedioso incluso para hacer un simple SELECT, en este caso Workbench tiene opciones muy útiles para estos casos. Al hacer click derecho en una tabla (en general cualquier objeto) aparecen opciones como «Copy to clipboard -> Update statement» y zaz.. en memoria tenemos ya el comando SQL para actualizar la tabla, y si esta en el Clipboard, mejor, por que  podemos llevarlo a nuestro editor preferido para seguir programando. Siendo modesto esa opción puede ahorrar 5 valiosos minutos a cualquier programador.

Workbench SQL Editor - Showing errors and hide codeResaltado de errores y ocultado de código SQL
Cuando escribimos segmentos grandes de código SQL sobre todo en consultas anidadas, con llamadas a funciones, etc., suele ser difícil encontrar un error de anidamiento o bueno.. un error en resumidas cuentas, MySQL Workbench tiene la característica de mostrar los «horrores» de nuestro código, pero no siempre acierta pero sirve de mucho.
Al ocultar un segmento de código fastidioso, para entender mejor una consulta, en MySQL Workbench no es tan cómodo por el simple hecho de que no tienes mayores indicadores del código ocultado mas que un símbolo [+] y la secuencia numérica de lineas, a esta característica deberían agregarle algo al final para saber que algo continua y no eliminarlo por accidente.

Otras características que puedo comentar:

  • Impresionante!, es la palabra que merece el gestor de base de datos MySQL 5.1 , escribí numerosos procedimientos/funciones y consultas muy complejas, que antes eran imposibles, pero ahora las escribo con toda confianza y lo mejor de todo es que es super veloz!
  • SQL safe mode: es un modo de conexión que evita hacer modificaciones a toda la tabla con una consulta, por a si a alguien no le ha pasado alguna vez: eliminar toda una tabla/base de datos por accidente, el comando muy sencillo pero peligroso.
  • Todo esta a corta distancia: Todos los elementos de nuestra base de datos estan disponibles en el panel lateral y los tabs de la parte inferior, aun que quita espacio no deja de ser util, deberían optimizar esas vistas para tener mas espacio.
  • Los tabs siempre son utiles, donde quiera que estén.

Lo que mo ne gusta:

  • Con los procedimientos almacenados y funciones Workbench abre en un editor undividual por cada procedimiento/funcion para ser modificado/creado y para guardarlo hay que gastar mas de dos clicks innecesariamente, los clicks no cuestan nada pero fastidian. En este caso prefiero abrirlos directamente desde el editor (como lo hago en SQL Server).
  • Termina el programa cuando uno utiliza algun plugin de texto como los que cambian a mayusculas las palabras reservadaas. Tambien suele terminar el programa abruptamente en condiciones que aun desconozco, en cuanto tenga esa información voy a enviar el reporte de bug.
  • No hay mas plugins, hubiera esperado al menos uno pero lamentablemente no hay mas plugings (la pagina esta en mantenimiento).
  • Tabs: Workbench devuelve automaticamente un tab por resultado, es incomodo revisar cada tab si esque estamos haciendo un seguimiento.
  • No hay una funcion para imprimir un mensaje directamente (como el comando print en SQL Server),  para simular algo asi se puede utilizar una consulta de seleccion que incluya la variable para mostrarla.
  • Algunas veces en el panel de resultados uno ve el simbolo de [blob] cuando espera un resultado de menos de 100 caracteres, esto si que molesta por que sucede cuando utilizas la funcion CONCAT(…), la cadena de resultado no es muy grande para que Workbench lo considere como BLOB.

Algunos lectores seguramente me van a increpar la comparacion con SQL Server, pero debo decirles que Workbench me parece mucho mas util (en este caso) que el editor de consultas del Enterprise Manager, pero aun hay cosas que deben madurar.

Download!
Pueden descargar Workbench directamente desde:

http://dev.mysql.com/downloads/workbench/

Update 5-mar: Acaban de lanzar MySQL Workbech 5.2.32 hace unas horas, lo he descargado e instalado pero persiste un error que he reportado como bug: http://bugs.mysql.com/bug.php?id=60354

 

Oracle compra a Sun: ¿Qué pasará con MySQL?

Después de mucho tiempo tengo que comentar un acontecimiento muy estremecedor: Oracle, la mayor compañía que provee software de bases de datos, se compró a Sun Microsystems. Y como sabemos Sun hace algún tiempo compró MySQL que es una amenaza a Oracle por que MySQL es el gestor de base de datos mas utilizado en el mundo (claro que no tiene las mismas prestaciones).

Los que conocen la base de datos Oracle saben que Java esta presente en todas partes, y creo que ahora estará mucho mas. ¿Pero que pasará con MySQL?

No quiero ser muy desalentador pero dentro de muy poco veremos artículos relacionados a «Consejos para migrar una base de datos MySQL a Oracle» o peor aun titulares como «Oracle decide dejar de lado a MySQL».

Hoy, el día de mi cumpleaños, se ensombreció con esta noticia ya que soy seguidor de MySQL casi desde sus inicios, lo he visto mejorar y crecer como base de datos hasta ser lo que es ahora: un gestor de base de datos respetable.

Debo decir finalmente que no estoy seguro de lo que va a suceder en los próximos días, pero creo que serán los últimos días del soporte de MySQL, la comunidad de software libre tendrá que reunir sus mejores elementos para que este proyecto siga.

Fuente de la noticia:
http://www.sun.com/third-party/global/oracle/index.jsp

Update:
Michael Widenius tambien ha estado preocupado por lo mismo y hace algun tiempo ha iniciado un pedido muldial para ayudar a MySQL, ha tenido exito y da las gracias por el apoyo:
Su mensaje: http://www.helpmysql.org/en/thanks

Poniendo a prueba MySQL

MySQL
Hace unas semanas tengo planeado volcar algo de 13 millones de registros en mi servisor MySQL que corre sobre Fedora 3 con 1Gb de memoria.

Es imposible que se presenten problemas al momento de efectuar la prueba por que heché un vistazo a los casos de estudio que publica MySQL, solo tendré que cambiar ligeramente la configuracion y con el dolor de mi corazon reiniciar el servidor MySQL.

MySQL – Case Studies
http://www.mysql.com/why-mysql/case-studies/

La cantidad de datos y la infraestructura con la que trabajan estas empresas no se comparan con lo que tengo aqui, pero veremos que pasa. La siguiente semana les comentaré como me fué.

Maldita sea…!

Un sabor amargo me queda despues de hoy!

Sucede que estamos en medio de la implantación de un pequeño software en la Municipalidad de Puno y hace algunas horas nos dimos con la sorpresa que el tipo de dato time_t incrustado en la clase CTime solo soporta fechas desde 01/01/1970 al 31/12/2039… maldita sea!

Tendremos que trabajar algunas horas extra solucionando ese «problemita».

Se había tomado la decisión de guardar las fechas en segundos para poder hacer mejor los cálculos posteriormente, creo que eso no va a cambiar. Pero se trabajo de igual manera con el resto de campos de tipo fecha. (craso error)

El problema saltó cuando se intentó registrar a alguien que había nacido en el año 1949: ¡Horror!

¿Por que no nos dimos cuenta? Aun que el problema pueda ser solucionado con unas cuantas líneas de código y previa modificación del modelo de la base de datos, ¿Por qué no pensaron en esto? (Esto se parece al problema de la memoria base de 256K) Creo que echarle la culpa a otros es de malos amigos, así es que dejémoslo ahí.

De ahora en adelante, utilizaremos la clase COleDatetime que evitarán sorpresas futuras y post’s como éste.

PD. Hay que estar preparados para el año 2039.

Problema solucionado ODBC Connector

MySQL Generalmente me conecto a MySQL con ayuda del controlador ODBC que provee el mismo MySQL. Como sabemos todo MySQL esta en pledo desarrollo, ocurre que se presentan situaciones que no fueron contempladas, por consiguiente hay errores que perjudican el desarrollo haciendo que uno tome precausiones antes de utilizar un codigo especifico. Muchos hemos crecido con MySQL y creo que si no hubiera sido asi lo hubieramos desechado por detalles como este que les voy a mostrar a continuacion.

Para no darle mas vueltas al asunto concretamente el problema es como sigue:

Cuando se intentaba leer un campo varchar (o relacionado) que este vacio o NULL, el controlador ODBC lo reconocía como UNKNOWN, evidentemente no podía realizarse el paso de valores al tipo CString o char* del Visual C++.

Para evitar ese problema se tenía que averiguar la longitud del campo que se va a leer, algo asi como esto:

ULONG len = 0;
rs.GetAccessor()->GetLength(2,&len); // segundo campo
if(len > 0)
{
	rs.GetFieldValue(2,sValue);
	//...
}

Esto sucedia con las versiones del ODBC Connetor inferiores a la 3.51.12. Ahora el codigo anterior se reduce a la linea que lee el campo y hace el paso del valor a la variable.