El truco para ésto es utilizar subconsultas.

Lo más probable es que al pensar en esto, escriban un ejemplo como el siguiente:

UPDATE
  tabla1
SET
  campo = 'nuevo_valor'
WHERE
  campo_de_referencia = (
    SELECT
      tabla1.valor
    FROM
      tabla1,
      tabla2
    WHERE
      tabla1.campo = 'viejo_valor'
      AND
      tabla1.clave_primaria = tabla2.clave_foranea
      AND
      tabla2.campo_de_referencia = 'otro_valor'
  )
;

Lamentablemente, ésto no va a funcionar y van a obtener el siguiente error.

You can't specify target table 'tabla1' for update in FROM clause

Esto se debe a que como restricción, no puede actualizarse una tabla y al mismo tiempo hacer una consulta sobre si misma.

¿Cuál es la solución entonces?, utilizar un alias para la subconsulta.

UPDATE
  tabla1
SET
  campo = 'nuevo_valor'
WHERE
  campo_de_referencia = (
    SELECT
      valor
    FROM
      (
        SELECT
          tabla1.valor
        FROM
          tabla1,
          tabla2
        WHERE
          tabla1.campo = 'viejo_valor'
          AND
          tabla1.clave_primaria = tabla2.clave_foranea
          AND
          tabla2.campo_de_referencia = 'otro_valor'
      )
    AS alias_tabla1
  )
;

Ahora si, nuestra subconsulta queda encerrada en un alias, y ese alias es el que se aplica para la subconsulta en el update.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Cómo crear un trigger con un Definer específico en Mysql
• Duplicando una tabla en Mysql
• Cambiando el Definer de un Procedure en Mysql
• Convirtiendo de Timestamp a Date desde Mysql

Es en ese pasaje cuando descubrimos que el usuario que tenemos asignado está totalmente restringido sólo a nuestra base de datos, y hay ciertas operaciones que pueden resultar imposibles de resolver.

Un escenario posible seria al intentar crear un trigger, obtengamos un error por falta de privilegios.

Si además de éste usuario, podemos acceder a uno con privilegios más elevados (el usuario root es el habitual), podríamos crear el trigger.

Esto tampoco nos va a servir, porque cuando el usuario sin privilegios quiere ejecutar el trigger, le será negada la operación ya que el propietario del trigger es quien lo creó (en este coloquial ejemplo, sería propiedad del usuario root).

Ahora bien, la forma de poder crear un trigger pero asignándole un propietario que no se corresponde con el usuario que esté ejecutando, seria la siguiente:

CREATE DEFINER = 'usuario'@'host' TRIGGER mi_trigger BEFORE INSERT ON mi_tabla
  FOR EACH ROW BEGIN
 
  /* El código que tengamos que usar */
 
END;

De ésta forma, al crearlo con el usuario con privilegios, vamos a poder ejecutar la sentencia de creación del trigger y éste va a estar disponible para el usuario restringido que le indiquemos.

(Más que post esto parece un post-it)

A lo mejor te interese leer

• Cambiando el Definer de un Procedure en Mysql
• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Duplicando una tabla en Mysql
• Convirtiendo de Timestamp a Date desde Mysql

Una forma rápida de hacer esa prueba sin afectar los datos, es hacer una copia de la tabla.

En realidad, si tenemos tiempo siempre será más cómodo llevar esos datos a un entorno de staging para trabajar más tranquilos; vamos a pensar que no tenemos tiempo… y mucho menos un entorno se staging.

Si queremos duplicar nuestra tabla, sólo debemos ejecutar la siguiente instrucción:

CREATE TABLE tabla_nueva LIKE tabla_original;

De ésta forma. obtenemos una tabla idéntica en cuanto a estructura.

Si necesitamos los datos de esa tabla en nuestra copia, insertamos todos los registros de la original de la siguiente forma:

INSERT INTO tabla_nueva SELECT * FROM tabla_original;

Al haber una correspondencia exacta en cuanto a las columnas y tipos de datos, los registros son insertados sin mayor problema.

Hay una segunda forma de obtener el mismo resultado que las dos consultas previas. Podemos, con una sola instrucción, lograr la misma tabla.

En este caso, debemos ejecutar:

CREATE TABLE tabla_nueva SELECT * FROM tabla_original;

Con esto, dos formas muy rápidas de duplicar una tabla y, si se quiere, sus datos.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Cómo crear un trigger con un Definer específico en Mysql
• Cambiando el Definer de un Procedure en Mysql
• Convirtiendo de Timestamp a Date desde Mysql

Hubo un pequeño error a causa de la falta de control (tanto de nuestro lado como del de los implementadores), y cuando se importó la base de datos, se crearon los Procedure con un usuario propietario que no era el mismo que teníamos para acceder a la base de datos.

Luego de lidiar un rato, logramos que nos facilitaran el usuario root de Mysql, y ahí fue otro cantar.

Antes de conseguir el usuario, uno de los caminos era arreglar el script sql y mandarlo nuevamente para que se borrara la base de datos y se volviera a importar.

Si bien cumple su cometido, hay otro aún más sencillo e igual de efectivo.

Ya con un usuario con los permisos necesarios, para conocer qué Procedures tenemos definidos en nuestras bases de datos dentro de Mysql, sólo es necesario correr ésta consulta.

SELECT * FROM mysql.proc;

Así veremos todos los que tengamos definidos, sin importar ninguna condición.

Para el problema que se había presentado, había que modificar el propietario (Definer) de esas funciones. Por suerte, nada que un par de queries no puedan arreglar.

Lo primero es aislar el set de registros que vamos a modificar, al menos, como seguridad.

Para eso, corremos esta consulta.

SELECT * FROM mysql.proc WHERE definer = 'usuario1@dominio1';

Vamos a ver todos las funciones que están definidas con ese usuario como propietario.

Ahora, para cambiarlo, alcanza con hacer un update a esos registros. En nuestro ejemplo, correríamos ésta otra consulta.

UPDATE mysql.proc SET definer = 'usuario2'@'dominio2' WHERE definer = 'usuario1@dominio1';

Y para finalizar, hacemos efectivos los cambios en los privilegios.

FLUSH PRIVILEGES;

Asunto resuelto, ya tenemos arreglado este pequeño problema de permisos.

A lo mejor te interese leer

• Cómo crear un trigger con un Definer específico en Mysql
• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Duplicando una tabla en Mysql
• Convirtiendo de Timestamp a Date desde Mysql

La pregunta se refería a cómo pasar una fecha en formato Timestamp al formato Date (una representación más humana).

Lo primero que pensé fue en usar Php (por asumir qué así lo quería hacer), pero no, lo que quería era sacar el registro, directamente desde la base de datos, aplicando la conversión en el propio Mysql al momento de la consulta.

Como ya me ha pasado en otras ocasiones, supuse que encontraría en la documentación alguna función mágica que resolviera el problema… y por suerte, no me equivoqué.

Para convertir directamente desde la consulta una fecha desde timestamp a date, sólo hay que aplicar la siguiente función:

select from_unixtime(1224815188);

El resultado que obtenemos es:

2008-10-24 00:26:28

Nada más, con eso, problema resuelto.

Para más referencias sobre funciones de fecha, pueden mirar en la documentación oficial.

(Otro post cortito y al pié).

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Cómo crear un trigger con un Definer específico en Mysql
• Duplicando una tabla en Mysql
• Cambiando el Definer de un Procedure en Mysql

La forma de restaurar una base de datos Mysql desde la consola, tomando un backup, sería asi.

mysql -u usuario -p basededatos < basededatos.sql

El escenario que estoy suponiendo, implica que la base de datos que están queriendo importar no existe en su servidor Mysql.

Si este supuesto es correcto, se van a encontrar con un problemita, o mejor dicho, con un mensaje al ejecutar el comando.

ERROR 1049 (42000): Unknown database 'basededatos'

Esto se debe a la inexistencia de la base dentro de nuestro Mysql.

Tenemos dos maneras de resolver ésta situación.

1. Editar el archivo sql y agregarle a mano los comandos necesarios para la creación de la base.
2. Agregar dos parámetros a nuestro comando mysqldump.

En el primer caso, deberíamos agregar a nuestro archivo, las siguientes instrucciones.

CREATE DATABASE basededatos;
USE DATABASE basededatos;

Con esto, el script funcionaría correctamente. Lo malo de ésta forma, es que si tenemos backups muy muy pesados, puede resultar algo engorroso estar editándolos.

Para evitarnos este paso, vamos a cambiar la forma de ejecutar mysqldump.

Lo habitual y más simple para hacer el backup sería ejecutar el comando de ésta forma.

mysqldump -hhost -uusuario -ppassword basededatos > basededatos.sql

Como ya dije, esto no nos funcionará correctamente. Así que vamos a sumar algunos parámetros para estar más tranquilos.

Los parámetros en cuestión son:

• databases
• add-drop-database

Con databases mysqldump agregará automáticamente las instrucciones de creación y uso de base de datos.

Ahora bien, podría darse que por algún motivo, la base de datos existiera. Para evitar el conflicto, es que agregamos add-drop-database. Con ésto, nos garantizamos que se agregue la instrucción de dropeo de la base de datos antes de la instrucción de creación de la misma.

Nuestro nuevo dump se ejecutaría asi.

mysqldump --add-drop-database --databases -hhost -uusuario -ppassword basededatos > basededatos.sql

Ahora si, cuando volvamos a ejecutar la restauración, nuestra base de datos debería quedar restaurada sin problema alguno.

A lo mejor te interese leer

• Backup de bases de datos en Mysql
• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Restaurar un backup plano en PostgreSql
• Cómo crear un trigger con un Definer específico en Mysql

Uno de los cambios fue en el algoritmo de autenticación que utiliza la base de datos.

Muchos de los programas que se utilizaban, hicieron lo propio, y también actualizaron; pero hubieron algunos que no lo lograron (por los motivos que sea). En mi caso, fue el DBDesigner el que me trajo algo de dolor de cabeza.

Al querer conectarse, se obtenía un poco agradable mensaje que rezaba.

Client does not support authentication protocol requested
by server; consider upgrading MySQL client

Por suerte, existe una solución de compatibilidad.

El truco está en la forma en que especificamos la contraseña del usuario que vamos a usar desde el cliente problemático. La instrucción para lograr que dicho usuario se conecte sería la siguiente.

mysql> SET PASSWORD FOR 'usuario'@'host' = OLD_PASSWORD('contraseña');

Es la función old_password la encargada de garantizarnos la compatibilidad.

Como siempre, una visita por la documentación oficial nunca está de más.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Cómo crear un trigger con un Definer específico en Mysql
• Duplicando una tabla en Mysql
• Cambiando el Definer de un Procedure en Mysql

OPTIMIZE TABLE tabla;

Lo que logramos es eliminar por completo todo el espacio ocupado por registros que ya han sido borrados. Si esto lo pensamos sobre una tabla que tiene, como mínimo, miles de escrituras diarias, vamos a poder ver cómo ayuda la ejecución periódica de ésta sentencia.

Para más información, la documentación oficial.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Cómo crear un trigger con un Definer específico en Mysql
• Duplicando una tabla en Mysql
• Cambiando el Definer de un Procedure en Mysql

En mi caso, no había forma de acceder a Mysql. El usuario root no respondía en lo más mínimo. Es por eso que recurrí a mi memoria y a mis apuntes, y me dispuse a cambiar la contraseña del usuario root.

A continuación, los pasos para cuando nos topemos con la misma situación (el ejemplo está basado en su aplicación sobre Linux).

Detenemos el servicio de Mysql.

/etc/init.d/mysql stop

Luego vamos a iniciarlo en modo seguro, saltándonos la seguridad de usuario

mysqld_safe --skip-grant-tables &

Ahora si, invocamos a Mysql.

mysql

Nos paramos sobre la base de datos de Mysql.

mysql> USE mysql;

Una vez que se nos confirme el cambio, ingresamos la siguiente consulta.

mysql> UPDATE user SET password=PASSWORD('contraseña') WHERE user = 'root';

Y para finalizar.

mysql> FLUSH PRIVILEGES;

Ahora si, ya tenemos al usuario root con la contraseña que querramos.

Por supuesto, usamos el caso del usuario root por presuponer que no hay forma de acceder y queremos retomar el control del usuario con mayor privilegio dentro del Mysql, pero este procedimiento podría aplicarse para cualquier usuario que querramos… incluso, esta forma de ingresar en el motor, sirve para ejecutar cualquier acción.

A lo mejor te interese leer

• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Cómo crear un trigger con un Definer específico en Mysql
• Duplicando una tabla en Mysql
• Cambiando el Definer de un Procedure en Mysql

Si leíste mis últimos posts, creo que se nota la importancia que le doy al resguardo de la información.

Es por eso que vamos a ver que sencillo es hacer un backup de una base de datos de Mysql.

Lo único que necesitamos, es ejecutar el siguiente comando.

mysqldump -hhost -uusuario -ppassword basededatos > basededatos.sql

Si bien es bastante calaro, vamos con la explicación del comando.

• mysqldump es el comando propiamente dicho.
• -h le indica el host del cual vamos a hacer el backup.
• -u el usuario con los privilegios necesarios para acceder a la base de datos.
• -p contraseña del usuario.
• nombre de la base de datos a backupear.
• al final, el nombre que le querramos poner al backup generado.

Listo, esto puede ir a un script, ya sea la plataforma que uses, y dejarlo automatizado.

A lo mejor te interese leer

• Restaurar backups de Mysql
• Simulando show tables y describe de Mysql en PostgreSql
• Update con Subselect en Mysql
• Restaurar un backup plano en PostgreSql
• Cómo crear un trigger con un Definer específico en Mysql