¿Cómo puedo solucionar el error # 1064 de MySQL?

Al emitir un comando a MySQL, recibo el error # 1064 “error de syntax“.

  1. Qué significa eso?

  2. ¿Cómo puedo arreglarlo?

TL; DR

El error # 1064 significa que MySQL no puede entender su comando. Arreglarlo:

  • Lee el mensaje de error Te dice exactamente en qué parte de tu comando MySQL se confundió.

  • Verifique el manual. Al comparar con lo que MySQL esperaba en ese momento , el problema suele ser obvio.

  • Verifique las palabras reservadas. Si el error ocurrió en un identificador de objeto, verifique que no sea una palabra reservada (y, si lo es, asegúrese de que esté correctamente citado).

  1. Aaaagh !! ¿Qué significa # 1064?

    Los mensajes de error pueden parecerse a una jerigonza, pero son (a menudo) increíblemente informativos y brindan detalles suficientes para identificar lo que salió mal. Al comprender exactamente lo que MySQL le está diciendo, puede armarse para solucionar cualquier problema de este tipo en el futuro.

    Como en muchos progtwigs, los errores de MySQL están codificados de acuerdo con el tipo de problema que ocurrió. Error # 1064 es un error de syntax.

    • ¿Qué es esta “syntax” de la que hablas? ¿Es brujería?

      Mientras que “syntax” es una palabra que muchos progtwigdores solo encuentran en el contexto de las computadoras, de hecho se toma prestada de una lingüística más amplia. Se refiere a la estructura de la oración: es decir, las reglas de la gramática ; o, en otras palabras, las reglas que definen qué constituye una oración válida dentro del lenguaje.

      Por ejemplo, la siguiente oración en inglés contiene un error de syntax (porque el artículo indefinido “a” siempre debe preceder a un sustantivo):

      Esta oración contiene error de syntax a.

    • ¿Qué tiene eso que ver con MySQL?

      Cada vez que se emite un comando a una computadora, una de las primeras cosas que debe hacer es “analizar” ese comando para darle sentido. Un “error de syntax” significa que el analizador no puede entender lo que se solicita porque no constituye un comando válido dentro del lenguaje: en otras palabras, el comando viola la gramática del lenguaje de progtwigción .

      Es importante tener en cuenta que la computadora debe comprender el comando antes de que pueda hacer algo con él. Debido a que hay un error de syntax, MySQL no tiene idea de lo que está buscando y, por lo tanto, se da por vencido antes de que siquiera mire la base de datos y, por lo tanto, el esquema o el contenido de la tabla no son relevantes.

  2. ¿Cómo lo arreglo?

    Obviamente, uno necesita determinar cómo es que el comando viola la gramática de MySQL. Esto puede sonar bastante impenetrable, pero MySQL está tratando realmente de ayudarnos aquí. Todo lo que tenemos que hacer es …

    • ¡Leer el mensaje!

      MySQL no solo nos dice exactamente dónde el analizador encontró el error de syntax, sino que también hace una sugerencia para solucionarlo. Por ejemplo, considere el siguiente comando SQL:

      UPDATE my_table WHERE id=101 SET name='foo' 

      Ese comando produce el siguiente mensaje de error:

      ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE id=101 SET name='foo'' at line 1

      MySQL nos dice que todo parecía estar bien hasta la palabra WHERE , pero luego se encontró un problema. En otras palabras, no esperaba encontrar WHERE en ese momento.

      Los mensajes que dicen ...near '' at line... simplemente significan que el final del comando se encontró inesperadamente: es decir, algo más debería aparecer antes de que el comando termine.

    • ¡Obedece las órdenes!

      MySQL también recomienda que ” verifiquemos el manual que corresponde a nuestra versión de MySQL para utilizar la syntax correcta “. Vamos a hacer eso.

      Estoy usando MySQL v5.6, así que me referiré a la entrada manual de esa versión para un comando UPDATE . Lo primero en la página es la gramática del comando (esto es cierto para cada comando):

       UPDATE [LOW_PRIORITY] [IGNORE] table_reference SET col_name1 ={ expr1 |DEFAULT} [, col_name2 ={ expr2 |DEFAULT}] ... [WHERE where_condition ] [ORDER BY ...] [LIMIT row_count ] 

      El manual explica cómo interpretar esta syntax en Convenciones tipográficas y de syntax , pero para nuestros propósitos es suficiente reconocer que: las cláusulas que figuran entre corchetes [ y ] son opcionales; barras verticales | indicar alternativas; y las elipsis ... denotan una omisión por brevedad, o que la cláusula anterior puede repetirse.

      Ya sabemos que el analizador creía que todo lo que estaba en nuestro comando estaba bien antes de la palabra clave WHERE , o en otras palabras, hasta e incluyendo la referencia de la tabla. Al observar la gramática, vemos que la table_reference la table_reference debe ser seguida por la palabra clave SET : mientras que en nuestro comando, en realidad fue seguida por la palabra clave WHERE . Esto explica por qué el analizador informa que se encontró un problema en ese punto.

    Una nota de reserva

    Por supuesto, este fue un simple ejemplo. Sin embargo, siguiendo los dos pasos descritos anteriormente (es decir, observando exactamente en qué parte del comando el analizador encontró la gramática que se violaría y comparando con la descripción del manual de lo que se esperaba en ese momento ), prácticamente todos los errores de syntax pueden identificarse fácilmente.

    Digo “prácticamente todo”, porque hay una pequeña clase de problemas que no son tan fáciles de detectar, y es ahí donde el analizador cree que el elemento de lenguaje encontrado significa una cosa, mientras que usted intenta que signifique otra. Toma el siguiente ejemplo:

     UPDATE my_table SET where='foo' 

    Una vez más, el analizador no espera encontrar WHERE en este punto, por lo que generará un error de syntax similar, pero no se pretendía que fuera una palabra clave SQL: ¡había tenido la intención de identificar una columna para actualizar! Sin embargo, como se documenta en Nombres de objeto de esquema :

    Si un identificador contiene caracteres especiales o es una palabra reservada, debe citarla cada vez que se refiera a ella. (Excepción: una palabra reservada que sigue a un punto en un nombre calificado debe ser un identificador, por lo que no necesita ser citada). Las palabras reservadas se enumeran en la Sección 9.3, “Palabras clave y palabras reservadas” .

      [ deletia ] 

    El carácter de cita del identificador es el backtick (” ` “):

     mysql> SELECT * FROM `select` WHERE `select`.id > 100; 

    Si el modo SQL ANSI_QUOTES está habilitado, también se permite citar identificadores entre comillas dobles:

     mysql> CREATE TABLE "test" (col INT); ERROR 1064: You have an error in your SQL syntax... mysql> SET sql_mode='ANSI_QUOTES'; mysql> CREATE TABLE "test" (col INT); Query OK, 0 rows affected (0.00 sec) 

Si recibe el error con SQuirreL Client al ejecutar una rxpression de SQL con un punto y coma como CREATE PROCEDURE, entonces necesita el complemento de MySQL. Puede seleccionarlo en la instalación. No está seleccionado por defecto.

Para mi caso, estaba tratando de ejecutar el código de procedimiento en MySQL, y debido a algún problema con el servidor en el que el Servidor no puede encontrar dónde terminar la statement, recibí el Código de Error 1064. Así que terminé el procedimiento con DELIMITER personalizado y funcionó bien

Por ejemplo, Antes de que fuera:

 DROP PROCEDURE IF EXISTS getStats; CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime) BEGIN /*Procedure Code Here*/ END; 

Después de poner DELIMITER, fue así:

 DROP PROCEDURE IF EXISTS getStats; DELIMITER $$ CREATE PROCEDURE `getStats` (param_id INT, param_offset INT, param_startDate datetime, param_endDate datetime) BEGIN /*Procedure Code Here*/ END; $$ DELIMITER ; 

También obtiene este error cuando intenta insertar JSON u otros datos con caracteres especiales, sin las comillas necesarias, por ejemplo:

 UPDATE myTable SET myJSONfield = {}; 

cambiarlo a

 UPDATE myTable SET myJSONfield = '{}'; 

Varias razones para ello … digamos por ejemplo si declaramos cualquier variable, entonces debería ser antes de cualquier otro tipo de declaraciones. o si no, tenemos que poner un bloque BEGIN antes de eso.

 DECLARE _RoomID INTEGER ; SET _dtTodayTmp=NOW(); SET _dtToday=DATE_FORMAT(_dtTodayTmp,"%m/%d/%y"); SET _tmNow=DATE_FORMAT(_dtTodayTmp,"%h:%i:%s"); DECLARE tree_cursor1 CURSOR FOR SELECT roomid FROM reservationDet rd WHERE rd.status=3 AND rd.compcode=pCompCode; 

da error, así que tenemos que hacerlo

 DECLARE _RoomID INTEGER ; SET _dtTodayTmp=NOW(); SET _dtToday=DATE_FORMAT(_dtTodayTmp,"%m/%d/%y"); SET _tmNow=DATE_FORMAT(_dtTodayTmp,"%h:%i:%s"); **BEGIN** DECLARE tree_cursor1 CURSOR FOR SELECT roomid FROM reservationDet WHERE STATUS = 3 AND compcode = pCompCode ; 

Puede ser porque su cadena o los datos insertados contienen una sola comilla ‘ puede intentar

 mysql_real_escape_string() for mysql or mysqli_real_escape_string() for mysqli 

función para escapar de la cadena al insertar datos (insertar consulta) en la base de datos.