Error insert into mysql

Learning PHP with MYSQL from w3schools. Everything is going fine but when i am trying to enter multiple value into table and it shows below error.

Error INSERT INTO MyGuests (firstname, lastname, email) VALUES ('John', 'Doe', 'john@example.com')INSERT INTO MyGuests (firstname, lastname, email) VALUES ('Mary', 'Moe', 'mary@example.com')INSERT INTO MyGuests (firstname, lastname, email) VALUES ('Julie', 'Dooley', 'julie@example.com')
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 'INSERT INTO MyGuests (firstname, lastname, email) VALUES ('Mary', 'Moe', 'm' at line 2

Here is my code Sample

$server = 'localhost';
$username = 'root';
$password = '';
$database = 'envy';

// Create Connection
$conn = new mysqli($server, $username, $password, $database);

if($conn->connect_error){
    die("Connected Successfully.".$conn->connect_error);
}

$sql = "INSERT INTO MyGuests (firstname, lastname, email)
VALUES ('John', 'Doe', 'john@example.com')";

$sql .= "INSERT INTO MyGuests (firstname, lastname, email)
VALUES ('Mary', 'Moe', 'mary@example.com')";

$sql .= "INSERT INTO MyGuests (firstname, lastname, email)
VALUES ('Julie', 'Dooley', 'julie@example.com')";

if($conn->query($sql)==TRUE){
    $lastid = $conn->insert_id;
    echo "New Record Created successfully. Last id: ". $lastid;
}else{
    die("Error ".$sql."<br>".$conn->error);
}

$conn->close();

As a beginner i don’t where is the problem. I wrote the exact code like the tutorial but

Here is a link to the tutorial. http://www.w3schools.com/php/php_mysql_prepared_statements.asp

SQL query INSERT not working inserting values into my DB [duplicate]

I’m trying to insert some values into my DB but it’s not working, i’m trying to figure out why it’s not working but I’m an amateur php coder,

This is the code I’m using:

And the rows i’m trying to insert into are: id,title,body,date,by
but it’s not showing up in the database or on my news page.

Can someone please help me?

5 Answers 5

by is a special keyword. Try wrapping the column names in tick marks:

I would expect id to be your primary key. It should not allow a null value. If it is auto incrementing you might try this:

Others have noted by is a reserved word so you will need to quote it. It is best to avoid naming database objects using reserved words. Consider renaming the by column to author .

You should consider making changing the query into a prepared statement. See How can I prevent SQL injection in PHP?.

First of all, don’t put the single quotes around NULL or else it will be entered as a string.

Also, I am assuming that you are using mysql_real_escape_string to sanitize $title, $body, etc.

As mellamokb pointed out, by and date are special keywords. It’s best practice to put ticks around your columns (and table names). (this will fix your query)

I recommend using sprintf & mysql_real_escape_string to handle SQL injection attack possibilities:

This will let you know what error is encountered too.

That said, there are numerous potential issues:

• by is a reserved keyword, you need backticks to escape its use in MySQL (see example above). The alternative is to rename the column to something that is not a reserved word — backticking every column and/or table name hides such issues rather than learning
• NULL should not be inside of single quotes, or it will be interpreted as a string; DEFAULT would be another option if there’s a DEFAULT constraint on the column
• the date column should be either a DATE, DATETIME or TIMESTAMP data type rather than string in order to use MySQL Date/Time functionality, and should be using DATE_FORMAT if the value will not be a MySQL standard date format

Источник

SQL insert into values where not exists

I am trying to execute the following query

its giving error. where am i wrong ?

1064 — 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 not exists(select trans_id,ledger_code_1 from test where **trans_id = 1 and’ at line 1

is there any other solution ? i have primary key as auto number..

3 Answers 3

You might consider a different approach.

It appears from your code that you’re trying to avoid the existence of two statements with the same trans_id and ledger_code_1 values. If that’s a correct statement of your problem, you should protect those two columns with a UNIQUE index (or consider making them the primary key of the table if that’s appropriate).

If you do that, you can issue the INSERT statement without having to worry about the logic to avoid the duplicate insertion. You will have to trap an exception if the record already exists.

The advantage of this approach is that you’re guaranteed never to violate the data integrity of those two columns, even if you write additional SQL in the future and forget to include the condition, or if you modify the data in the tables directly.

The disadvantage (aside from having to trap the exception) is that it only works if you 100%, never, ever, ever want to allow those duplicate records. If there is an occasional instance in which you do (for instance, it’s true of trans_id 1, but not trans_id 999) then you’re stuck with applying your integrity checks in the application code.

Источник

INSERT INTO wont work!

im having some problem with this code:

i am connected to db
the users column ID is auto_increment

I get this when adding or die mysql_error in sql statement: 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 ‘ )’ at line 2

7 Answers 7

You’re missing quotes around the inserted values:

surround both with single quotes

The error message tells you you have a syntax error in your SQL in line 2. So something about the code

is wrong. Specifically you need quote characters around the parameters:

Try putting ‘ marks around the variables in the insert:

what is the type of fields username and password ? strings ? wrap with «

Others gave you the right answer.

Maybe here, you can add another variable so you can see the problem next time. And, next time, don’t forget to test your query in a frontend for MySQL (MySQL Query Browser, PHPMyAdmin or so. )

A safer way to do this would be to use a prepared statement. Something like this:

I used the following web page to get this snipped: http://www.petefreitag.com/item/356.cfm and it has more information about using the bind_param method. (This example is also for php5). The concept of using prepared statements is not limited to php and is widely used in many languages for both performance and security optimizations.

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.14.43159

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Раскрываем магию MySQL или о строгости и мягкости MySQL

Очень часто в интернете встречаюсь со статьями, в которых приводят кучу примеров с якобы странным поведением MySQL по сравнению с другими БД. Чтобы стало понятно, о чём я говорю, приведу несколько примеров:
1. Деление на ноль возвращает NULL вместо ошибки
2. Выход за диапазон допустимых значений неявно приводит число к допустимому значению, а не к ошибке и откату транзакции
3. Вставка неверного типа данных также приводит к неявному преобразованию и успешному выполнению операции
Таких примеров я могу привести огромное число, но цель статьи не сделать очередное собрание высосанных из пальца примеров, а объяснить, почему происходит то или иное действие. Вся эта мистика MySQL давно описана в документации и легко объяснима, в чём вы сможете убедиться сами, прочитав статью до конца.
Для меня эта первая статья на хабре, поэтому я старался писать дотошно подробно. Уверен, что она будет полезна всем, кто работает с MySQL. Большую помощь в написании статьи оказала подготовка к сдаче на сертификат разработчика MySQL, а точнее книга «MySQL Certification Study Guide».
Итак, мой друг, начнём!

SQL Modes

SQL modes – это настройка поведения работы сервера MySQL, состоящая из режимов, каждый из которых контролирует какой-либо один аспект обработки запроса.

Возможности SQL mode:
1. Устанавливает строгую или мягкую проверку входных данных
2. Включает или отключает следование SQL стандарту
3. Обеспечивает лучшую синтаксическую совместимость с другими БД
По сути, SQL mode очень мощный механизм тюнинга БД, позволяющий гибко манипулировать обработкой запросов и уведомлениями MySQL.

Прежде чем мы перейдём к последующей теории, вы должны строго-настрого уяснить, что изменение режима SQL mode после создания и вставки данных в партиционные таблицы (partitioning tables) может привести к существенным изменениям в поведении таких таблиц, что, в свою очередь, может привести к потере или повреждению данных. Настоятельно рекомендуется, чтобы вы никогда не изменяли SQL режим после создания партиционных таблиц.
При репликации партиционных таблиц, отличающиеся параметры SQL mode на Primary и Slave MySQL серверах также может привести к проблемам. Для стабильной работы репликации между серверами, настройки SQL mode должны быть идентичными.

Теперь, после того, как вы осознали всю ответственность в использовании SQL режимов, перейдём к его сути.

Контроль текущего SQL режима происходит через системную переменную sql_mode. Для задания значения используется команда SET. Ниже представлены возможные варианты установки данного режима.

1. Соответствует значению по умолчанию для только что установленной БД (никаких специальных режимов не установлено). Кавычки являются обязательными.

2. Установка одного режима sql_mode. Возможно два варианта – с кавычками и без них.

3. Установка нескольких режимов sql_mode. Указание кавычек является обязательным!

Несмотря на то, что названия режимов регистронезависимые, я для удобства прочтения буду везде в статье писать их в верхнем регистре.

В примерах выше мы устанавливали режимы для текущей сессии, но если вы обладаете привилегиями суперпользователя, то можно задать глобальный режим для всего сервера и всех текущих коннектов, указав параметр GLOBAL. Полный синтаксис установки sql_mode выглядит так:

Для просмотра текущих значений глобального и сессионного режима сервера используйте следующие запросы:

Помимо команды SET существует ещё два способа задания режима работы БД:
1. Запустить сервер с опцией —sql-mode=» »
2. Установить в файле my.cnf (для unix подобных систем) или my.ini (для windows) параметр sql-mode=» «

Краткий справочник режимов

ANSI_QUOTES

Заставляет сервер интерпретировать двойную кавычку ( » ) точно также, как и обратную кавычку ( ` ), при этом она теряет способность обрамлять строки. Как можно было догадаться, этот режим заставляет MySQL приблизиться к SQL стандарту.

IGNORE_SPACE

По умолчанию, между функцией и открывающейся круглой скобкой нельзя устанавливать пробелы. Включение этого режима разрешает серверу игнорировать пробелы, но платой за такую вольность станет то, что все функции станут зарезервированными словами, а значит, при совпадении имени столбца с именем функции придётся в обязательном порядке экранировать такой столбец.

ERROR_FOR_DIVISION_BY_ZERO

При делении на ноль в строгом режиме генерируется ошибка, а нестрогом — предупреждение при выполнении операторов INSERT или UPDATE. Без этого параметра деление на ноль возвращает предупреждение и вставляет в таблицу NULL. Про строгость будет сказано в следующем режиме, пока постарайтесь абстрагироваться.

В приведённых примерах мы получали исключительно предупреждения, потому что строгий режим был выключен. Понимание строгости очень важное понятие для БД MySQL, потому что в классических базах данных такого нет. Забегая вперёд, скажу, что все БД изначально строгие и не позволяют тех вольностей, которые есть в MySQL. Мягкость MySQL сложилась исторически, когда ещё не было InnoDB. Посудите сами, в нетранзакционных таблицах действуют совершенно другие правила, нежели чем в транзакционных, поэтому следование жестким правилам зачастую приводило бы к нежелательному результату.

STRICT_TRANS_TABLES

Включает «строгий режим» для всех таблиц, поддерживающих транзакции, т.е. на InnoDB и BDB. Этот режим возвращает ошибку, вместо предупреждения в следующих случаях:
1. Тип входных данных не соответствует заданному типу. Например, вставка строки в колонку c числовым типом
2. Число или дата находится вне допустимого диапазона. Диапазон определяется типом данных. Например, для типа unsigned tinyint допустимым диапазоном являются числа от 0 до 255
3. При вставке данных пропущено значение колонки, для которой не задано значение по умолчанию и имеет атрибут NOT NULL
4. Длина значения выходит за пределы заданного диапазона. Например, для колонки типа CHAR(5) вы не сможете вставить строку более 5 символов
5. Для типов ENUM и SET отсутствует вставляемое или обновляемое значение
Более подробно об особенностях работы данного режима будет рассказано отдельно в последующей ниже главе.

STRICT_ALL_TABLES

STRICT_ALL_TABLES полностью идентично STRICT_TRANS_TABLES, но действие режима уже распространяется на все таблицы MySQL, а не только на транзакционные.
Из-за разницы подходов к работе транзакционных и не транзакционных таблиц не всегда есть смысл использовать данный режим. Если это вам ещё не очевидно, то в главах о строгом и нестрогом режимах вы поймёте разницу.

TRADITIONAL

Композитный режим, включает в себя целый набор режимов, в который входит «строгий режим», а также ряд других режимов, налагающих ограничения на входные данные.
Заставляет MySQL вести себя как большинство «традиционных» баз данных SQL.
Посмотрим на полный перечень режимов, который содержит в себе данный режим.

Другой композитный режим, делающий MySQL «ANSI-подобным», т.е. приближенным к стандарту SQL.
Включает в себя следующие режимы: REAL_AS_FLOAT, PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE.
Последние два режима были обсуждены ранее, поэтому кратко опишу первые два:
REAL_AS_FLOAT – тип данных real является синонимом float, а не double.
PIPES_AS_CONCAT – разрешает использовать для конкатенации строк ( || ), вместо логического ИЛИ.

ONLY_FULL_GROUP_BY

Генерирует ошибку в запросах, в которых GROUP BY имеет не полный список не агрегированных параметров из SELECT и HAVING.

Если вы желаете узнать обо всех SQL mode режимах и окунуться глубже в проблему, то милости прошу в официальную документацию http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html

Работа с SQL mode в PHP

По правде сказать, данную главу вряд ли можно назвать прикладной, потому что в реальных проектах конфигурировать нужно непосредственно на сервере MySQL, а не средствами языка программирования, поэтому глава скорее теоретическая, но для общего развития неплохо иметь ввиду и такой способ.
Чаще всего соединение с БД происходит через экземпляр класса PDO, поэтому рассмотрим его в деталях.
Есть два способа передать в БД специальные инструкции. Первый способ – передача в конструкторе. Посмотрим на полное описание конструктора:

Думаю, с первыми тремя параметрами всё и так понятно, а вот $driver_options как раз таки предоставляет нам возможность выполнять запросы непосредственно в БД. Для задания системной переменной sql_mode режимом TRADITIONAL, будем делать так:

Второй способ – конфигурирование на лету, через метод setAttribute;

Конечно, некоторые из вас могут возразить, что можно выполнять запросы методом query или exec, но поскольку изначально глава теоретическая, то не буду заострять внимание на таком способе.
Дополнительно о PDO можно прочитать в официальной документации php.net/manual/ru/book.pdo.php
Предопределённые PDO константы для работы с MySQL php.net/manual/ru/ref.pdo-mysql.php

Строгий режим

Мы уже немного познакомились со строгим режимом в главе SQL Mode, когда изучали режимы STRICT_TRANS_TABLES, STRICT_ALL_TABLES и композитный TRADITIONAL. Уже из самого названия легко догадаться, что все входные данные проверяются с особой тщательностью и в случае нарушений любых ограничений, вас неминуемо будет ждать ошибка.
Ошибка в транзакционных таблицах вызывает откат транзакции (rollback). Даже если ваши запросы не предварены командой start transaction, то неявно каждый запрос в отдельности по-любому будет обёрнут командами start transaction и commit. Так работают все традиционные БД, что в равной степени относится и к транзакционным таблицам MySQL. Из этого следует, что нарушив ограничение, вызывается rollback, который откатывает все изменения.
Для не транзакционных таблиц всё немного сложнее. Так, при вставке, обновлении или удалении нескольких строк, в случае ошибки отменяется только последнее действие, вместо полного отката. Проиллюстрирую это на примере.

Генерация ошибки происходит в следующих случаях:
1. Тип вставляемых данных отличается от заданного типа столбца
2. Опущено значение для столбца, которому не задано значение по умолчанию и имеет атрибут NOT NULL
3. Для чисел и дат – данные находятся вне диапазона допустимых значений
4. Для строк – превышение допустимой длины
5. Для типов ENUM и SET – значение не является допустимым для заданного перечисления
6. Для столбца, определённого как NOT NULL — вставка NULL

Дефолтные значения для типов данных

Если в insert запросе не указаны данные для одной из колонок, то MySQL будет обрабатывать эту ситуацию в следующем порядке:
1. Если столбец имеет значение по умолчанию, то используется это значение и на этом всё заканчивается, в противном случае происходит переход к следующему шагу
2. Если столбец не имеет параметр NOT NULL, то присваивается NULL и на этом всё заканчивается, в противном случае поведение зависит от переменной sql_mode, точнее от строгости самого режима.

Как можно было догадаться из предыдущей главы, строгий режим сразу вернёт ошибку, которая в свою очередь откатит транзакцию для транзакционных таблиц или отменит последнее действие для не транзакционных таблиц.

Для нестрого режима будет вставлено значение по умолчанию для заданного типа данных.
Значения по умолчанию для каждого типа данных:

• Для типов int и float значение по умолчанию ноль (0)
• Для всех строк, кроме типа enum – пустая строка (»)
• Для enum – первый нумерованный член
• Для даты и времени – нулевые значения ‘0000-00-00 00:00:00’
• Для timestamp — текущая дата и время, если колонка была автоматически инициализирована, либо нулевыми значениями ‘0000-00-00 00:00:00’

Нестрогий режим

Ура! Наконец-то, мы добрались до самой «загадочной» части статьи, которую некоторые освещают как некую магию MySQL, но, увы, это лишь фокусы на потеху детей. И так, поехали!
Возможно, нужно было ранее описать все случаи, для которых применяются правила проверки данных, но я решил сделать это только сейчас. Их всего три, но каждый из них требует отдельного рассмотрения.
Запросы на модификация данных: INSERT, UPDATE, REPLACE, LOAD DATA INFILE
Обновление описания схем таблиц: ALTER TABLE
Задание значения по умолчанию (DEFAULT) в описании колонки

Напоминаю, что в строгом режиме некорректные данные приведут к генерации ошибки и откат данных, а в нестрогом – значение будет не явно приведено к корректному значению и сгенерировано предупреждение. Для просмотра ошибок используйте SHOW WARNINGS.
Ниже будут подробно рассмотрены все случаи обработки некорректных значений и их разрешений на уровне БД.

Выход из диапазона допустимых значений

Если число меньше минимального значения допустимого диапазона, то присваивается минимально-допустимое число. Если больше максимального – максимально-допустимое.

Обработка строк

Строки длиннее заданной длины — усекаются.

ENUM и SET типы данных

Если присваиваемое значение колонке с типом ENUM не перечислено в определении ENUM, то MySQL преобразует его в пустую строку.
Если значение, которое присваивается SET столбцу содержит элементы, которые не перечислены в определении SET, то MySQL отбрасывает эти элементы, сохраняя значения только легальным элементам.

Преобразование в тип даты

При попытке сохранения значения, которое не может быть преобразовано в тип данных столбца, MySQL неявно преобразует его в значение по умолчанию для данного типа.

Таблица преобразований

Присвоение NULL для колонки с NOT NULL

Результат зависит от того, будет вставлена одна строка или множество в INSERT запросе.
При вставке одной строки возникает ошибка и изменения не применяются. При множественной вставке — MySQL неявно преобразует значение по умолчанию для этого типа данных.

Обновление описания схем таблиц: ALTER TABLE

При изменении типа данных на колонку налагаются ограничения нового типа, что может привести к неожиданному изменению самих данных по правилам описанных выше.

Если на колонку налагается ограничение NOT NULL, то все NULL значения конвертируются в значения по умолчанию для заданного типа данных текущей колонки. Значения по умолчанию описаны в главе «Дефолтные значения для типов данных»

Задание значения по умолчанию (DEFAULT) в описании колонки

Вообще, всё уже было сказано в прошлой главе, поэтому здесь нечего добавить.

Ну что ж, мой дорогой читатель. Теперь ты можешь по-праву назваться настоящим джедаем и получить чёрный пояс)))

Извлекаем плюсы

IGNORE

Ключевое слово IGNORE заставляет MySQL включать для такого запроса нестрогий режим. Также его можно использовать для генерации предупреждения вместо ошибки, при нарушении целостности первичного ключа (PRIMARY KEY) или уникальности (UNIQUE).

ON DUPLICATE KEY UPDATE

Такой вид запроса не совсем идеальный пример, но включил, чтобы лишний раз вспомнить, что такое вообще существует. Используется для выполнения вставки данных, либо обновлении при нарушении ограничения целостности первичного ключа (PRIMARY KEY) или уникальности (UNIQUE).

Источник

Код ошибки 1064: Синтаксическая ошибка

select LastName, FirstName,
from Person

Возвращает сообщение:

Код ошибки: 1064. У вас есть ошибка в синтаксисе SQL; проверьте руководство, соответствующее версии вашего сервера MySQL, для правильного синтаксиса для использования рядом с «от лица» по строке 2.

Получение сообщения «Ошибка 1064» из MySQL означает, что запрос не может быть проанализирован без ошибок синтаксиса. Другими словами, он не может понять смысл запроса.

Цитата в сообщении об ошибке начинается с первого символа запроса, который MySQL не может понять, как разбираться. В этом примере MySQL не может иметь смысла в контексте from Person . В этом случае перед from Person появляется дополнительная запятая. В запятой говорится, что MySQL ожидает другого описания столбца в предложении SELECT

Синтаксическая ошибка всегда говорит ... near '...' . Вещь в начале цитат очень близка к ошибке. Чтобы найти ошибку, посмотрите на первый токен в кавычках и на последний токен перед кавычками.

Иногда вы получите ... near '' ; то есть ничего в кавычках. Это означает, что первый символ, который MySQL не может понять, находится в конце или в начале инструкции. Это предполагает, что запрос содержит несбалансированные кавычки ( ' или " ) или несбалансированные круглые скобки или что вы не закончили утверждение раньше.

В случае хранимой процедуры вы, возможно, забыли правильно использовать DELIMITER .

Итак, когда вы получаете Error 1064, посмотрите текст запроса и найдите точку, указанную в сообщении об ошибке. Визуально проверяйте текст запроса прямо вокруг этой точки.

Если вы попросите кого-нибудь помочь вам устранить ошибку 1064, лучше всего предоставить как текст всего запроса, так и текст сообщения об ошибке.

Код ошибки 1175: безопасное обновление

Эта ошибка появляется при попытке обновления или удаления записей без включения WHERE , которое использует столбец KEY .

Чтобы выполнить удаление или обновление в любом случае — введите:

SET SQL_SAFE_UPDATES = 0;

Чтобы снова включить безопасный режим, введите:

SET SQL_SAFE_UPDATES = 1;

Код ошибки 1215: не удается добавить ограничение внешнего ключа

Эта ошибка возникает, когда таблицы недостаточно структурированы для обработки быстрой проверки соответствия требованиям внешнего ключа ( FK ), которые требуется разработчику.

CREATE TABLE `gtType` (
  `type` char(2) NOT NULL,
  `description` varchar(1000) NOT NULL,
  PRIMARY KEY (`type`)
) ENGINE=InnoDB;

CREATE TABLE `getTogethers` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `type` char(2) NOT NULL,
  `eventDT` datetime NOT NULL,
  `location` varchar(1000) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_gt2type` (`type`), -- see Note1 below 
  CONSTRAINT `gettogethers_ibfk_1` FOREIGN KEY (`type`) REFERENCES `gtType` (`type`)
) ENGINE=InnoDB;

Примечание1: такой KEY, как это будет создан автоматически, если это необходимо из-за определения FK в строке, которая следует за ним. Разработчик может пропустить его, и при необходимости добавится KEY (aka index). Пример того, что он пропускает разработчик, показан ниже в someOther .

До сих пор так хорошо, пока не позвонил.

CREATE TABLE `someOther` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `someDT` datetime NOT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT `someOther_dt` FOREIGN KEY (`someDT`) REFERENCES `getTogethers` (`eventDT`)
) ENGINE=InnoDB;

Код ошибки: 1215. Невозможно добавить ограничение внешнего ключа

В этом случае он не работает из-за отсутствия индекса в ссылочной таблице getTogethers для обработки быстрого поиска eventDT . Решить в следующем утверждении.

CREATE INDEX `gt_eventdt` ON getTogethers (`eventDT`);

Таблица getTogethers была изменена, и теперь создание someOther будет успешным.

На странице руководства MySQL с использованием ограничений FOREIGN KEY :

MySQL требует индексов для внешних ключей и ссылочных ключей, чтобы проверки внешнего ключа могли быть быстрыми и не требовать сканирования таблицы. В таблице ссылок должен быть индекс, в котором столбцы внешнего ключа перечислены в качестве первых столбцов в том же порядке. Такой индекс создается в таблице ссылок автоматически, если он не существует.

Соответствующие столбцы внешнего ключа и ссылочного ключа должны иметь похожие типы данных. Размер и знак целочисленных типов должны быть одинаковыми. Длина типов строк не обязательно должна быть одинаковой. Для небинных (символьных) строковых столбцов набор символов и сопоставление должны быть одинаковыми.

InnoDB позволяет внешнему ключу ссылаться на любой индексный столбец или группу столбцов. Однако в ссылочной таблице должен быть индекс, в котором ссылочные столбцы указаны в качестве первых столбцов в том же порядке.

Обратите внимание, что последняя точка выше первых (самых левых) столбцов и отсутствие требования первичного ключа (хотя и очень рекомендуется).

После успешного создания таблицы реферирования (дочернего) все ключи, которые были автоматически созданы для вас, видны с помощью следующей команды:

SHOW CREATE TABLE someOther;

Другие распространенные случаи возникновения этой ошибки включают, как упоминалось выше, в документах, но должны быть выделены:

• По-видимому тривиальные различия в INT который подписан, указывая на INT UNSIGNED .

• Разработчики испытывают трудности с пониманием многоколоночных (составных) KEYS и первых (самых левых) требований к порядку.

1045 Доступ запрещен

См. Обсуждения в «ГРАНТ» и «Восстановление пароля root».

1236 «невозможное положение» в репликации

Обычно это означает, что Мастер разбился и этот sync_binlog был выключен. Решение состоит в том, чтобы CHANGE MASTER to POS=0 следующего файла binlog (см. Мастер) в Slave.

Причина: Мастер отправляет элементы репликации в подчиненное устройство перед очисткой до его бинарного журнала (когда sync_binlog=OFF ). Если Мастер выйдет из строя до флеша, ведомый уже логически перемещается за конец файла в binlog. Когда мастер запускается снова, он запускает новый битблог, поэтому ПЕРЕЗАПУСК к началу этого бинарного журнала является наилучшим доступным решением.

Долгосрочное решение — sync_binlog=ON , если вы можете позволить себе дополнительный ввод-вывод, который он вызывает.

(Если вы работаете с GTID, …?)

2002, 2003 Не удается подключиться

Проверьте, заблокирован ли порт 3306 блокировки брандмауэра.

Некоторые возможные диагностические и / или решения

• Действительно ли сервер работает?
• «служба firewalld stop» и «systemctl disable firewalld»
• мастер telnet 3306
• Проверьте адрес bind-address
• проверить skip-name-resolve
• проверьте розетку.

1067, 1292, 1366, 1411 — Плохая стоимость для числа, даты, по умолчанию и т. Д.

1067 Это, вероятно, связано со значениями по умолчанию TIMESTAMP , которые со временем изменились. См. TIMESTAMP defaults на странице «Даты и времена». (которого еще нет)

1292/1366 DOUBLE / Integer Проверьте наличие букв или других синтаксических ошибок. Убедитесь, что столбцы выровнены; возможно, вы думаете, что ставите в VARCHAR но выровнены с числовым столбцом.

1292 DATETIME Проверьте слишком далеко в прошлом или будущем. Проверяйте между 2:00 и 3:00 утром, когда смена летнего времени изменилась. Проверьте наличие сильного синтаксиса, например, +00 часовых поясов.

1292 ПЕРЕМЕННЫХ Проверьте допустимые значения для VARIABLE вы пытаетесь SET .

1292 LOAD DATA Посмотрите на строку, которая является «плохим». Проверьте escape-символы и т. Д. Посмотрите на типы данных.

1411 STR_TO_DATE Неверно отформатированная дата?

126, 127, 134, 144, 145

Когда вы пытаетесь получить доступ к записям из базы данных MySQL, вы можете получить эти сообщения об ошибках. Эти сообщения об ошибках произошли из-за повреждения в базе данных MySQL. Ниже приведены типы

MySQL error code 126 = Index file is crashed
MySQL error code 127 = Record-file is crashed
MySQL error code 134 = Record was already deleted (or record file crashed)
MySQL error code 144 = Table is crashed and last repair failed
MySQL error code 145 = Table was marked as crashed and should be repaired

Ошибка MySQL, вирусная атака, сбой сервера, неправильное завершение работы, поврежденная таблица — причина этой коррупции. Когда он становится поврежденным, он становится недоступным, и вы больше не можете обращаться к ним. Чтобы получить доступность, лучший способ получить данные из обновленной резервной копии. Однако, если у вас нет обновленной или какой-либо действительной резервной копии, вы можете перейти на восстановление MySQL.

Если тип движка таблицы — MyISAM , примените CHECK TABLE , а затем REPAIR TABLE .

Тогда подумайте серьезно о преобразовании в InnoDB, поэтому эта ошибка больше не повторится.

Синтаксис

CHECK TABLE <table name> ////To check the extent of database corruption
REPAIR TABLE <table name> ////To repair table

139

Ошибка 139 может означать, что число и размер полей в определении таблицы превышают некоторый предел. обходные:

• Пересмотреть схему
• Нормализовать некоторые поля
• Вертикально разбить таблицу

1366

Обычно это означает, что обработка набора символов не была согласована между клиентом и сервером. См. … для дальнейшей помощи.

126, 1054, 1146, 1062, 24

(с перерывом). С учетом этих четырех номеров ошибок, я думаю, эта страница охватит около 50% типичных ошибок, которые получат пользователи.

(Да, этот «пример» нуждается в пересмотре.)

24 Не удается открыть файл (слишком много открытых файлов)

open_files_limit происходит из настройки ОС. table_open_cache должен быть меньше этого.

Это может привести к ошибке:

• Невозможность DEALLOCATE PREPARE в хранимой процедуре.

• PARTITIONed table (s) с большим количеством разделов и innodb_file_per_table = ON. Рекомендовать не иметь более 50 разделов в данной таблице (по разным причинам). (Когда «Родные разделы» станут доступными, этот совет может измениться.)

Очевидным обходным решением является увеличение ограничения ОС: разрешить больше файлов, изменить ulimit или /etc/security/limits.conf или в sysctl.conf (kern.maxfiles & kern.maxfilesperproc) или что-то еще (зависит от ОС). Затем увеличьте open_files_limit и table_open_cache .

Начиная с 5.6.8 open_files_limit автоматически open_files_limit на основе max_connections , но это нормально, чтобы изменить его по умолчанию.

1062 — Повторяющийся ввод

Эта ошибка возникает в основном из-за следующих двух причин

1. Дублируемое значение — Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'

   Столбец первичного ключа уникален, и он не будет принимать дублируемую запись. Поэтому, когда вы пытаетесь вставить новую строку, которая уже присутствует в вашей таблице, это приведет к ошибке.

Чтобы решить эту проблему, установите столбец первичного ключа как AUTO_INCREMENT . И когда вы пытаетесь вставить новую строку, игнорируйте столбец первичного ключа или вставьте значение NULL в первичный ключ.

CREATE TABLE userDetails(
  userId INT(10) NOT NULL AUTO_INCREMENT,
  firstName VARCHAR(50),
  lastName VARCHAR(50),
  isActive INT(1) DEFAULT 0,
  PRIMARY KEY (userId) );

--->and now while inserting 
INSERT INTO userDetails VALUES (NULL ,'John', 'Doe', 1);

1. Уникальное поле данных — Error Code: 1062. Duplicate entry 'A' for key 'code'

   Вы можете назначить столбец как уникальный, и попытка вставить новую строку с уже существующим значением для этого столбца приведет к этой ошибке.

Чтобы преодолеть эту ошибку, используйте INSERT IGNORE вместо обычного INSERT . Если новая строка, которую вы пытаетесь вставить, не дублирует существующую запись, MySQL вставляет ее как обычно. Если запись является дубликатом, ключевое слово IGNORE отбрасывает ее, не генерируя никаких ошибок.

INSERT IGNORE INTO userDetails VALUES (NULL ,'John', 'Doe', 1);