Resulta que tengo en MySQL una tabla con varios datos, de distintos tipos, y una clave primaria. Si quiero ver cómo está armada, le echo un describe:
mysql> describe prueba; +-----------+-------------+------+-----+--------+-------+ | Field | Type | Null | Key | Default| Extra | +-----------+-------------+------+-----+--------+-------+ | transact | varchar(20) | | PRI | | | | campo1 | varchar(8) | | | | | | campo2 | int(2) | | | 0 | | | campoN | varchar(20) | | | | | +-----------+-------------+------+-----+--------+-------+ 4 rows in set (0.00 sec)
Todo bien hasta ahora.
Tengo un sistema, que maneja transacciones, y en un determinado momento escribe un nuevo registro en esa tabla. Luego, segundos o minutos después, el sistema va a la tabla y levanta los datos grabados, ya que recibe el mismo código de transacción que antes.
Considerando que la transacción es clave primaria en la tabla, yo sabía que podía encontrar un registro, o ninguno en el caso de que la segunda vez me hayan pasado un registro incorrecto. Grande fue mi sorpresa al ver que mi sistema fallaba de forma inesperada. Luego de tracear al bug hasta su origen, terminé viendo que la consulta me generaba no cero, ni un registro, ¡sino dos!
Sin poder creerlo, fui a la base de datos, a mano, y tiré la siguiente consulta...
mysql> SELECT * FROM prueba where transact=20060905093655001974; +----------------------+----------+--------+------------+ | transact | campo1 | campo2 | campoN | +----------------------+----------+--------+------------+ | 20060905093655001908 | 23540003 | 1 | 1234567890 | | 20060905093655001971 | 00435665 | 1 | 0987654321 | +----------------------+----------+--------+------------+ 2 rows in set (0.01 sec)
Acá se me rompieron un poquito las estructuras, pero lo logré resolver.
En unos días posteo la solución (o mejor dicho, el desenlace). Pero a aquel/lla que lo explique primero, lo/a invito una cerveza.
