Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

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

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

Вот и сейчас, вместо того, чтобы нормально прочитать все результаты ПОСЛЕ выполнения конкретного мультизапроса, он зачем-то попытался сделать "патч", который делал бы это ПЕРЕД выполнением следующего. А точнее - вообще любого, просто на всякий случай - вдруг перед ним был мультизапрос.
"Где логика, где разум?"

При этом он сам не понимает, что именно он хочет исправить. Ему показали два варианта: есть нормальный, когда программист должен сам прочитать результаты всех запросов, и есть кривой, когда результаты можно выкинуть, не читая. И вот этот второй вариант он зачем-то хочет "реализовать". То есть "патч", который делает то, что и так есть.

Вообще я стал замечать, что когнитивные способности у многих ровесников ухудшаются. На Stack Overflow есть чувак с рейтингом под миллион, и сейчас он с трудом берет в толк простейшие вопросы :(
И это, в общем, всех нас ждёт.
Но тому хотя бы пока хватает соображения понимать, что дело в нём, и он не начинает выступать на тему что все вокруг идиоты. Потому что он и раньше был адекватным. А здесь всё осложняется синдромом непризнанного гения.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

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

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

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

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

поведение от версии к версии не зависит, только от настроек

выкладки - это не код, а выводы, расчеты, умозаключения. Они у вас неправильные. Вы смотрите в документацию (правильную), на логи (очевидные) а выводы делаете неправильные. Про это даже анекдот есть:

Опыт №1: берем таракана, отрываем две ноги, свистим, таракан убегает.
Опыт №2: отрываем таракану четыре ноги, свистим, таракан убегает.
Опыт №3: отрываем таракану все ноги, свистим, таракан на месте.
Вывод: таракан без ног не слышит

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Akina, чтобы у человека наступило, этот человек должен сомневаться в первую очередь сам в себе, проверять свои выкладки. Так работает научный подход. А у нашего героя ровно наоборот - кругом дураки, а он непогрешимый гений в белом пальто :)
Вот и сейчас: у него есть все данные, чтобы разглядеть элементарное объяснение наблюдаемого эффекта, когда поведение как раз должно отличаться. Причем эффекта стороннего, который наблюдается очень редко. Потому что все люди выполняют запросы нормально, как описано в мануалах.
Но чванство убивает мозг. Чувак забронзовел. А когда ты перестаешь сомневаться в себе и свои проблемы начинаешь списывать либо на тупость собеседников, либо на несуществующие "баги" в языке - тут уже голова перестаёт работать...

Присвоить значение массива переменной?

Как мне по другому идентифицировать/обратиться к конкретному имени?

ЗАЧЕМ? Что вы по этому имени хотите получить? Узнать, есть ли на него дата, или нет?

Присвоить значение массива переменной?

Ну так Иванов Иван Иванович и есть ключ. Почему нельзя по нему обратиться?
И как вы вообще будете знать, какой ключ ставить - а или б?
или вам надо для любой даты обоих получить? Тогда тем более переменные не подходят.

Экранирование sql запросов, достаточно ли функции?

Рука-лицо. Комментарий из серии "угадал все буквы, не угадал слово".

Присвоить значение массива переменной?

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

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Вот он и он пишет, что чтобы получить ошибку, результат надо получить. А не выкидывать, как это делаете вы.
Давайте уж я вам разжую, чтобы вы больше не отнимали время у занятых людей.
ваши инсерты работают потому что в режиме эмуляции
почему происходит ошибка, вам разжевали на гитхабе - потому что вы не запросили результаты своих запросов, и они остались ждать на сервере. чтобы ошибки не было, эти результаты надо либо получить, либо выкинуть (при этом смысл cделать запрос, но не проверять его результат от меня ускользает).
при этом если результат не запросить, то ошибка и не будет в нем отражена.
совершенно очевидное поведение, когда локальная переменная уничтожается по завершении работы функции (которое пытаетесь формулировать через какой-то детский лепет про "параллельное выполнение" ) как раз это и делает: по завершении работы функции всем её переменным делается unset. чем и объясняется все загадочное волшебство, происходящее в ваших примерах.
при этом куда проще выполнять запросы по одному: тогда не нужно проверять результат каждого вручную, плюс не зависеть от режима эмуляции.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Боже, я и подумать не мог, что вы реально побежите писать нелепый баг-репорт в РНР. Судя по всему, именно его вы называете словом stackowerflow. И разумеется, в своей манере переврали сказанное там, причем с точностью до наоборот. Там написано не будет отражено, а вы мне толкаете что будет.

Стоит ли хранить изображения base64 в БД?

rakas, два вопроса
1. вас посетители сайта никогда не били за такой адов трафик?
2. а почему так много? Там карта звёздного неба в разрешении 144 мегапикселя?

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

В случае PDO SQL запроса не через prepare() - вроде закрывает.

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

Стоит ли хранить изображения base64 в БД?

2-4 МБ - это все картинки или одна?

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

почему мы не падаем с ошибкой прямо на этом запросе?

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

если бы мы упали, как мне объяснили на StackOverflow, это было бы отражено в результате.

как обычно, там соврали

Таким образом, проблема в том, что дефолтный режим запросов - unbuffered query

здесь абсолютно не при чём

сам не закрывает соединение

с какого перепугу-то он будет закрывать

А вместо этого мы свели вопрос к тому, что я плохо от инъекций защитил код.

Это вы и свели, начав двигать свои гениальные идеи по защите от инъекций.

В чем нарушение синтаксиса в данном запросе? Как его исправить?

За таким, что по логике Джордж Клуни может оставить отзыв о жилье только если он его бронировал, а не просто с улицы пришёл. И отзыв будет привязан к конкретной брони. Из которой уже можно получить и пользователя, и жильё. А нет брони - нет и отзыва.
Соответственно, user_id здесь избыточно, поскольку оно уже есть в таблице бронирования. Как и номер комнаты.
То есть задача именно по жилью и юзеру найти бронь, и подставить её в отзыв.
Впрочем соглашусь, что в вопросе ничего этого нет.

А почему CROSS, а не INNER?

В чем нарушение синтаксиса в данном запросе? Как его исправить?

По условию задачи надо использовать CTE? или два запроса?
Можно увидеть полный текст условия?

В чем нарушение синтаксиса в данном запросе? Как его исправить?

И забудьте про SELECT COUNT(*) + 1. Это стрельба себе в ногу на поражение. прочитайте для чего служат уникальные идентификаторы и как ими пользоваться.

В чем нарушение синтаксиса в данном запросе? Как его исправить?

INSERT INTO Reviews (rating, reservation_id) VALUES (5, 
  SELECT id FROM Reservations
    WHERE user_id = (SELECT id FROM Users WHERE name = 'George Clooney')
    AND room_id = (SELECT id FROM Rooms WHERE address = '11218, Friel Place, New York')
)

Такой запрос не работает?

В чем нарушение синтаксиса в данном запросе? Как его исправить?

И непонятно, зачем здесь CTE.

В чем нарушение синтаксиса в данном запросе? Как его исправить?

Зачем вы пытаетесь выполнить два запроса одновременно?
Запросы выполняются по одному.