Ошибка MySQL: запрос был пуст (1065) для простого оператора INSERT

Question

Я пытаюсь запустить большой скрипт, который создает таблицу, а затем вставляет в нее почти 15 000 строк. Таблица создается очень хорошо, а затем на 833 INSERT я получаю ошибку:

Error: Query was empty (1065)

Вот мой 833-й оператор INSERT (который не выполняется):

INSERT INTO CLASSCODE (CLASS_CODE, CLASS_CODE_NAME, RATE_GROUP, PROGRAM_NM, ST_CODE, EFF_DT, EXP_DT) VALUES (10255, "Funeral Directors - incl PL other than Crematory  - 10255", 3, "Service", "AZ", 19980801, NULL);

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

INSERT INTO CLASSCODE (CLASS_CODE, CLASS_CODE_NAME, RATE_GROUP, PROGRAM_NM, ST_CODE, EFF_DT, EXP_DT) VALUES (10425, "Frame Shop - Picture/Posters                      - 10425", 2, "Retail", "AZ", 19980801, NULL);

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

Определение моей таблицы выглядит так:

CREATE TABLE CLASSCODE (
      CLASS_CODE INTEGER NOT NULL, 
      CLASS_CODE_NAME VARCHAR(60) NOT NULL, 
      RATE_GROUP SMALLINT NOT NULL, 
      PROGRAM_NM VARCHAR(20) NOT NULL, 
      ST_CODE CHAR(2), 
      EFF_DT DATE, 
      EXP_DT DATE) 

Я запускаю этот скрипт в браузере запросов MySQL с графическим интерфейсом.

Может ли это быть связано с количеством строк, которые я пытаюсь вставить? Нужно ли периодически совершать коммиты? Есть ли что-то простое, что я просто пропускаю?

Спасибо!

Answer 1

Наиболее распространенный сценарий, с которым можно столкнуться в файле сценария, это когда у вас где-то стоит двойная точка с запятой:

INSERT INTO CLASSCODE 
(CLASS_CODE, CLASS_CODE_NAME, RATE_GROUP, PROGRAM_NM, ST_CODE, EFF_DT, EXP_DT)
VALUES
(10255, "Funeral Directors - incl PL other than Crematory  - 10255", 3, "Service", "AZ", 19980801, NULL)
;;

Я бы сделал быстрый поиск по сценарию и увидел бы, есть ли ;; там вокруг строки 833.

Answer 2

Я бы предложил запустить sql из командной строки в терминале или в сеансе SSH. Интерфейс графического интерфейса может мешать или ограничивать вашу способность выполнять большое количество вставок.

Answer 3

Если вы беспокоитесь о вашем фактическом синтаксисе запроса, это нормально. Я создал вашу таблицу и запустил вставку, и это сработало. Когда вы говорите, что запускаете скрипт, у вас просто есть файл, полный исходного кода SQL, через который вы работаете? Раньше я сталкивался с ошибкой типа «Пустой запрос», когда люди использовали вещи типа JDBC и их логика зацикливания была испорчена.

Я думаю, что мы можем с уверенностью сказать, что это не тот конкретный оператор вставки, который вы вставили, это должно быть что-то, связанное с сервером или синтаксисом вокруг этого запроса в сценарии. Строки должны фиксироваться автоматически, если вы что-то не перенастроили. Вы можете попробовать запустить "show variable;" из командной строки mysql и добавив его сюда. Затем мы можем взглянуть на ваши настройки и посмотреть, выглядит ли что-нибудь странное.

Вы пытались переупорядочить некоторые из ваших вставок в файле? Это, по крайней мере, скажет нам, если это не удается на конкретном запросе или определенном месте в файле. Попробуйте изменить порядок вставок, чтобы посмотреть, не сработает ли он примерно в 833 году или не в другом месте. Если он попадает в одно и то же место, он звучит как память или что-то связанное с буфером. Если он поменяется местами, когда вы его переместите, я бы сказал, что у вас есть какой-то случайный персонаж (a или a. Возможно), лежащий где-то, как сказал @zombat.

Надеюсь, это поможет. Дайте нам знать, что вы можете.

Answer 4

Поскольку другие вставки работают нормально, и их структура, по-видимому, не отличается, я сначала подумал, что у вас не хватает какого-то ресурса с номером вставки 833.

Что произойдет, если вы выполните коммит после каждой вставки (возможно, в буфере транзакций не хватает места)? Это работает тогда? На самом деле, лучшим тестом будет один коммит с номером транзакции 800. Если затем вы превысите 833, то это ваша проблема.

Если это так, просто измените ваш сценарий (или сценарий, который создает идентификатор сценария, он автоматически генерируется), чтобы фиксировать каждые 100 или около того вставок (фиксация после каждой вставки, вероятно, сделает его невыносимо медленным).

Answer 5

Я столкнулся с той же ошибкой сегодня. По-видимому, когда я использовал подготовленные операторы для PDO: MySql, таблица имела нулевые данные при запросах.

Мне пришлось исправить все недостающие данные из таблицы.