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

Akina, спасибо, теперь я начал понимать, что там происходит под капотом. Я раньше был уверен, что подстановку (prepare) делает именно PHP, точнее драйвер. В Doctrine вон этим код DQL парсера вообще занимается. Не знал про специальную SQL команду для этого.

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

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

Ипатьев, но тем не менее, покажите плиз где это задокументировано на официальном сайте. Если в документации этого нет - это таки баг.

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

tukreb, по факту сейчас их в пределах полутора сотен. Дальше вряд ли станет сильно больше, учитывая размер и специфику проекта.

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

tukreb, "вам рано переходить на RAW SQL" - простите, но я с него начинал ещё году в 2007-2008, и в целом неплохо знаю SQL :)
А то, что код местами паршивый - ну так да, хороших привычек нет.

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

Ипатьев, поправил код второго примера, убрав полностью точки с запятой, а не только в рамках INSERT - и это действительно решило проблему. Спасибо, перепишу нормально.

Но я всё равно не понимаю, почему оно не работает с несколькими запросами - ведь разделить по точке с запятой и отправить несколько запросов в БД - это несложная операция? И PDO умеет её делать, судя по тому, что это работает у меня в других местах, и он при этом не выдаёт ни ошибок, ни предупреждений.

И почему есть разница в двух сценариях - с вложенным вызовом метода и без него?

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

Ипатьев, да, так выглядит симпатичнее, спасибо. Но причина ошибки же не в этом всё равно :)

И во втором примере я как раз сделал как вы сказали: заменил множественные INSERT на один с запятыми. У вас же претензия к наличию точек с запятой была?

Вы можете вообще выкинуть вставку второй строки (из двух в примере), и всё равно ничего не изменится.

И, кстати, ваш вариант в плане итогового результата ничем не отличается от моего второго примера, кроме наличия параметризации. Всё те же (val1, val2) группы через запятую.

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

Потому что API предназначено для выполнения запросов по одному

А многопоточность как же? Или здесь всё в один поток, потому что гарантируется порядок исполнения?

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

Ну и вообще, покажите, где написано, что нельзя использовать несколько запросов через точку с запятой. У меня всю жизнь это работало, ещё в mysql_query(), и не было никаких проблем.

Да, это визуально грязный и не очень аккуратный подход, но он рабочий и он разрешён.

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

запросы должны быть параметризованными

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

А она здесь в принципе нужна ради чего, для экранирования данных? Так эта таблица - доверенный источник, её в идеале редактирует только один человек, и проверяет её корректность.

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

Обратите внимание на второй сниппет - я поменял там формат INSERT-ов, сделав один вместо двух. И это вообще никаким образом на результат не влияет. По сути это не важно, PDO и нижележащий драйвер достаточно умные, чтобы интерпретировать обе формы записи одинаково.

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

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

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

Я добавил ещё один пример

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

А почему с ними будут проблемы? Если вызывать напрямую, а не как здесь (метод изнутри метода), то проблем нет. Мне кажется, вы немного не в ту сторону смотрите :) Проблема в том, что нужно закрывать курсор, но почему-то нигде в мануалах про это ни слова не сказано.

Ошибка сохранения Entity с cascade в Doctrine в Symfony 5 - как избежать?

Оказывается, там всё-таки было OneToOne. Спасибо

Ошибка сохранения Entity с cascade в Doctrine в Symfony 5 - как избежать?

Но там в коде так и есть, так что это не ответ на вопрос

Ошибка сохранения Entity с cascade в Doctrine в Symfony 5 - как избежать?

Да, вы правы, ерунду написал

Как исправить проблему запрета загрузки смешанного содержимого в Chrome?

dodo512, попробовал, к сожалению, не сработало. Но в этом исключительно моя вина: у меня CloudFlare настроен так, что он ходит только по HTTP, в этом вся проблема. Единственным рабочим способом оказалась подстановка HTTPS ссылок в Location на стороне Apache.

Я понимаю, что гораздо безопаснее режим Strict, когда CloudFlare получает данные по HTTPS, но у меня очень слабый комп стоит в качестве сервера стоит, и в этом режиме через очень короткое время начинается жуткий лагодром: очень долго открываются страницы, грузятся картинки и т.д. (3-4 секунды и более вместо 80-150 мс время загрузки фоновой фотографии в JPEG на главной странице сайта). Так что увы, пока только так.

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

jcmvbkbc, "проблемы будут у людей использующих кодовые страницы типа сp1251" - их на порядок меньше, только под них делать было бы совершенно глупо. Но если есть вариант, чтобы работало и у них, и у тех, у кого UTF-8 - я с радостью реализую.

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

jcmvbkbc, ну просто если эту строку убрать, то с русскими буквами возникает шляпа. Причём по-моему она возникает как раз не в cmd, а в консоли VS Code. Как ни странно, именно en_US.utf8 с русским текстом на моей русской винде работает нормально... Не факт правда, что так будет у людей с другой системной локалью.

Как реализовать кроссплатформенную поддержку Unicode в аргументах командной строки в C?

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

Какой выбрать легкий и простой дистрибутив Linux для серфинга интернета?

Griboks, тогда трудно судить о том, насколько он более лёгкий :)