Puesto que reporte esto al bug tracking tool de MySQL y ellos hicieron caso omiso, diciendome que el tipo BINARY leia binarios no caracteres y cerraron el tema (Esto yo ya lo sabia), cuando les pregunte otra cosa    quiero advertir a todos los que alguna vez quieran usar tipo de datos BINARY en sus tablas.

Tengo este escenario de ejemplo:

 
mysql> CREATE TABLE ejemplo(
    -> nombres BINARY(20));
Query OK, 0 ROWS affected (0.39 sec)
 
mysql> INSERT INTO ejemplo VALUES('Juan'),('Pepe'),('Jose');
Query OK, 3 ROWS affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 ROWS IN SET (0.00 sec)
 

Hasta ahi como pueden ver todo funciona perfectamente bien    ahora que ocurre si se quiere actualizar o eliminar algun dato, observen:

 
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = hex('Juan');
Query OK, 0 ROWS affected (0.00 sec)
ROWS matched: 0  Changed: 0  Warnings: 0
 
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = 'Juan';
Query OK, 0 ROWS affected (0.00 sec)
ROWS matched: 0  Changed: 0  Warnings: 0
 
mysql> DELETE FROM ejemplo WHERE nombres = 'Pepe';
Query OK, 0 ROWS affected (0.00 sec)
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 ROWS IN SET (0.00 sec)
 

Un poco chungo no??? no elimino, ni actualizo nada... (Utilize la funcion HEX por recomendacion de la gente de MySQL ya que ellos decian que usase esta funcion para actualizar los datos y cerraron el reporte del bug, pero obviamente No funciona como pueden ver).

Ahora se que muchos diran ese problema se resuelve con un simple ALTER si claro, observen:

 
mysql> DESCRIBE ejemplo;
+---------+------------+------+-----+---------+-------+
| FIELD   | TYPE       | NULL | KEY | DEFAULT | Extra |
+---------+------------+------+-----+---------+-------+
| nombres | BINARY(20) | YES  |     | NULL    |       |
+---------+------------+------+-----+---------+-------+
1 ROW IN SET (0.00 sec)
 
mysql> ALTER TABLE ejemplo MODIFY nombres VARCHAR(25);
Query OK, 3 ROWS affected (0.45 sec)
Records: 3  Duplicates: 0  Warnings: 0
 
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = 'Juan';
Query OK, 0 ROWS affected (0.00 sec)
ROWS matched: 0  Changed: 0  Warnings: 0
 
mysql> DELETE FROM ejemplo WHERE nombres = 'Pepe';
Query OK, 0 ROWS affected (0.00 sec)
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 ROWS IN SET (0.00 sec)
 

Agur... no funciona. He reiniciado el servidor MySQL he reiniciado mi PC, he vuelto a ingresar al motor despues de reiniciado todo he intentado nuevamente lo anterior expuesto y NADA sigue sin Eliminar o Actualizar ningun dato.

Este problemita aplica tambien para tablas con otro tipo de dato (CHAR, VARCHAR, etc) y le cambies dicho campo a BINARY con ALTER, por ejemplo:

 
mysql> CREATE TABLE ejemplo2(
    -> nombres VARCHAR(20));
Query OK, 0 ROWS affected (0.38 sec)
 
mysql> INSERT INTO ejemplo2 VALUES('pepe'),('Juan'),('pedro'),('luis');
Query OK, 4 ROWS affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+---------+
| nombres |
+---------+
| pepe    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 ROWS IN SET (0.00 sec)
 
 
 

Hasta ahi todo bien... de hecho puedo borrar o actualizar con el tipo de datos VARCHAR:

 
mysql> UPDATE ejemplo2 SET nombres = 'Cucu' WHERE nombres = 'pepe';
Query OK, 1 ROW affected (0.00 sec)
ROWS matched: 1  Changed: 1  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+---------+
| nombres |
+---------+
| Cucu    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 ROWS IN SET (0.00 sec)
 
 
 

Hasta ahi todo bien ahora miren esto:

 
mysql> ALTER TABLE ejemplo2 MODIFY nombres BINARY(20);
Query OK, 4 ROWS affected (0.27 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+----------------------+
| nombres              |
+----------------------+
| Cucu                 |
| Juan                 |
| pedro                |
| luis                 |
+----------------------+
4 ROWS IN SET (0.00 sec)
 
mysql> UPDATE ejemplo2 SET nombres = 'Marta' WHERE nombres = 'Cucu';
Query OK, 0 ROWS affected (0.00 sec)
ROWS matched: 0  Changed: 0  Warnings: 0
 
 
 

No actualizo el dato tampoco borra para el que quiera intentarlo, ahora hago nuevamente ALTER para que mi tipo de dato sea otra vez VARCHAR pensando vagamente que esto resolvera este problema:

 
mysql> ALTER TABLE ejemplo2 MODIFY nombres VARCHAR(20);
Query OK, 4 ROWS affected (0.10 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> DESCRIBE ejemplo2;
+---------+-------------+------+-----+---------+-------+
| FIELD   | TYPE        | NULL | KEY | DEFAULT | Extra |
+---------+-------------+------+-----+---------+-------+
| nombres | VARCHAR(20) | YES  |     | NULL    |       |
+---------+-------------+------+-----+---------+-------+
1 ROW IN SET (0.00 sec)
 
mysql> UPDATE ejemplo2 SET nombres = 'Marta' WHERE nombres = 'Cucu';
Query OK, 0 ROWS affected (0.00 sec)
ROWS matched: 0  Changed: 0  Warnings: 0
 
 
 

Como pueden ver en el campo Changed:0 indica que no actualizo los datos aun siendo VARCHAR    tampoco elimina los datos siempre y cuando usemos constantes digase campo = algo

Reiniciar el motor MySQL no resuelve este problema, tampoco reiniciar el servidor como tal.

Porque coloco esto aqui? por el simple hecho de que si alguien tuviera un foro como este, con tablas llenas de datos millones de ellos, y alguien de alguna manera hackea la DB y hace un ALTER y coloca campo BINARY y luego un ALTER para retornar a VARCHAR y digamos que ese campo donde se aplico eso, es el campo Mensajes (POST) del foro, y luego ese usuario se antoja de entrar al foro y insultar , ofender y llenarlo de SPAM y el Admin no va a poder eliminar dichos posts... y tampoco recibira Error no Warnings recibira nada... Y asumo que lo mismo podria ocurrir a la hora de Banear a un usuario por su nick.

Por eso posteo eso aca, porque aunque es dificil lograr acceder como admin a un motor MySQL para hacer estos cambios, siempre buscan la via de llegar, y no es nada gracioso para ningun DBA ver que no puede borrar ni actualizar datos del motor y No saber porque.

Un saludo.

No tengo idea de lo que haras....  pero espero que no sea negativo. Lo coloque aca porque aparentemente el equipo de desarrollo de SUN no esta en arreglar cosas internas de MySQL a no ser que sean extremadamente muy graves. Y puestos que ellos ignoraron el reporte y me dieron una respuesta un poco tonta y muy diferente a lo que yo les pregunte.... pues pense que era beneficioso colocar la info aca, mas para tener eso pendiente no para hacerle una broma a nadie.

El asunto se puede resolver haciendo un backup de toda la tabla, y al archivito de backup editarlo y colocarle VARCHAR y volver a cargar todos los datos ... pero imaginate un sitio de millones de datos ya alojados, y tener que empenarse a hacer el backup primero, luego editar el archivo y finalmente cargar todosss esos datos    algunas horas fuera de online sin duda.

En fin, para hacer lo anterior deberias tener acceso full a la tabla a la cual le haras el ALTER aunque con tanto hackeo y exploits que hay por ahi, no dudo que obtengan esto.

Lo puse en el Bugtracker... pero por mas que le cree el escenario con ejemplos y los pasos de prueba, y les especifique que el comando ALTER no cambiaba internamente el tipo de dato aunque visualmente 'Si' ellos... cerraron el tema diciendo que no era un BUG y diciendome que BINARY solo lee caracteres como binario (Algo que ya yo sabia) pero obviaron a toda costa el porque ALTER no aplica cuando cambias de tipo de dato.

No es la primera vez, que reporto algo en el bugtracking de MySQL y los developers hacen lo imposible por cerrar el reporte y hacer caso omiso. Hace un tiempo reporte uno donde eliminabas un tablespace y esto causaba que se eliminaran todos los tablespaces previos a la creacion de este ultimo ... en resumen perdias tablas de otro tablespace  y obviamente al perderlas no habia forma de recuperar nada. Ese reporte tambien me lo cerraron alegando que no era un BUG y unas semanas despues otro developer lo abrio nuevamente, y estaba preguntandole a quien le habian asignado el reporte que porque lo cerro si efectivamente el podia reproducir este bug en su MySQL.. y bueno mas developers se unieron y crearon un parche porque dedujeron que efectivamente era un BUG. Pero es normal que esos developers cierren casos para trabajar menos, ya me he enfrentado a estos casos y esta vez no voy a volver a abrir algo que ya he reportado.

Hola.

Para los que todavia no comprenden el bug (que es mas de funcionalidad del motor que otra cosa) el bug es que si tienes una tabla con campos VARCHAR y haces un alter sobre esa tabla (para cambiar el tipo de dato de los campos de VARCHAR a BINARY) el te accepta el cambio, pero despues no puedes eliminar ni actualizar ningun registro (data) dentro de la tabla. No sirve que vuelvas a alterar la tabla para cambiarla como estaba (acceptar tipos de datos VARCHAR) ya que no funciona, sigue sin hacer ningun cambio al tratar de eliminar o actualizar datos. El problema creo es como MySQL maneja el tipo de datos BINARY.

un saludo.

Orale Interesante , a decir vdd tampoco  comprendi mucho  del bug .. pero con tu explicacion ta quedas con la duda de .. el por que no le hicieron caso a tu  comentario ...