Почему sql запрос возвращает NULL?

Николай, Удалите из oc_product_attribute_test все записи, кроме 5-7 штук, проблемную тоже оставьте. Что-то типа DELETE FROM oc_product_attribute_test WHERE product_id NOT BETWEEN 19440 AND 19450; Проверьте, что проблема по-прежнему воспроизводится. Сделайте дамп и выложите - попробуем воспроизвести проблему и понять её источник.

А, ещё одно. Так, сбоку. А нафига нужен индекс KEY `1`? Он по идее вообще не должен использоваться ни в одном запросе, кроме тех, для которых он покрывающий.

Почему sql запрос возвращает NULL?

(null) - это NULL. Надеюсь, это вопросов не вызывает?

!(null), как я сказал выше, "!(NULL) - нормальное выражение булева типа, имеющее значение NULL".

Так что да - и то, и другое значение есть NULL. Который интерпретируется как FALSE (это я тоже говорил выше). Что в соответствии с логикой работы функции IF() (также описанной выше) приводит к выбору альтернативного значения. В обоих запросах.

И что не так-то? что не работает?

Почему sql запрос возвращает NULL?

Мне уже не нравится то, что данные в UTF8 (чарсет для отдельных полей не указан, значит, применяется дефолтный чарсет таблицы), тогда как и сервер, и соединение работают в UTF8MB4. Очень теоретически это может вызывать проблемы. А сверху ещё наслаиваются проблемы несовпадения COLLATION для данных и для литералов. MySQL в принципе считает эти чарсеты совместимыми, а collation вообще приводит неявно и хрен поймёшь по каким правилам...

Правда, всё это к именно описанной проблеме приводить не должно.

Так, следующий вопрос. Проблема - воспроизводима? т.е. если pa.product_id = 19442 косячит - то косячит абсолютно всегда? А если выгрузить десяток записей из таблицы, включая и запись для этого продукта, и положить в отдельную таблицу указанной структуры - всё равно проблема воспроизводится? А если этот же запрос выполнять не через PHP, а из клиента командной строки - проблема так же остаётся и воспроизводима?

PS. Charset / collation можно было бы дать текстом, как сделано для CREATE TABLE. А все три вывода - завернуть тегом кода, а не цитаты, для сохранения форматирования вывода.

Почему sql запрос возвращает NULL?

Дмитрий,

сразу лишаются смысла ибо при отсутствии записи будут давать один и тот же вариант.

Да, при отсутствии записи оба дадут 'NULL' (обращаю внимание - это не NULL, а 4-символьный строковый литерал с таким значением).

Насчёт смысла ничего не скажу - это к автору вопросы.

ибо кастинг null к boolean работать не будет

Да работает он, работает!

Правда, в MySQL ещё следует обычно учитывать неявное приведение типов (в нём вообще такого базового типа данных как BOOLEAN - нет), но не в данном случае. К слову, с точки зрения MySQL NULL при любых проверках действует как FALSE. Что обычно приводит к непониманию работы CHECK constraint, который, в отличие от IF(), проверяет, наоборот, на FALSE - но тут достаточно просто запомнить.

Почему sql запрос возвращает NULL?

Можно в MySQL запустить

Можно и не запускать. Ибо в полном соответствии с написанным выше оба запроса вернут двойку.

Почему sql запрос возвращает NULL?

Что-то у тебя всё плавает... запрос, который по твоему заверению возвращал "Шерсть", тут вернул "100% полиэстер", второй запрос вернул значение с маленькой буквы, хотя в вопросе написано с большой...

К самим значениям в хексах претензий нет - честная кириллица.

Структура таблицы oc_product_attribute

Это не структура, а, я извиняюсь, чушь собачья. Структура - это полный и не тронутый редактированием результат выполнения SHOW CREATE TABLE tablename;

Теперь проверяем второе подозрение. Выкладывайте структуру таблицы, а также результат выполнения SHOW VARIABLES LIKE 'char%'; и SHOW VARIABLES LIKE 'coll%';

Почему sql запрос возвращает NULL?

Предположу что стоит это понимать как то что NULL это специфическое значение, и для SQL и попытка привести к булеан через !(NULL) не работает;

Бред.

Напомню, что булево значение может иметь три разных варианта - TRUE, FALSE и UNKNOWN. Вот последнее в терминах SQL и есть NULL. Так что !(NULL) - нормальное выражение булева типа, имеющее значение NULL.

Логика работы IF() тупая и дубовая. Получили TRUE - выполняем первую альтернативу, иначе вторую, и неважно, FALSE это или NULL.

Почему sql запрос возвращает NULL?

Возвращает корректное значение - Шерсть

Что вернёт SELECT HEX(pa.text) FROM ... ?

Как исправить ошибку синтаксиса при COPY?

Думаю, проблема в том, что этот дамп предназначен для развёртывания в строго определённых условиях и строго определённым способом (например, копипастом в окно pgadmin), тогда как Вы используете какой-то другой способ.

Код ожидает, что строки с данными будут передаваться через stdin. И завершение строк с данными строкой "\." говорит о том же - эти символы явно должны интерпретироваться как команда клиента, не требующая подтверждения нажатием Enter. А вот клиент уже ожидает следующего запроса - при выполнении COPY он обнаружил, что из stdin ему брать нечего, и успокоился на копировании нуля записей.

Почти убеждён, что между отдельными значениями полей там не пробелы, а табуляции.

PPS. Код можно было бы и под спойлер спрятать...

PHP не создаёт запись MySQL, ошибки не выводит, что делать?

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

Почему не работает запрос к базе?

Собери текст запроса в отдельной переменной, а не в $mysql->query, покажи, что получилось.
Проверь, выполняется ли полученный запрос через CLI.
Включи обработку ошибок mysqli.

PHP не создаёт запись MySQL, ошибки не выводит, что делать?

No index used in query/prepared statement ...

Это не от MySQL прилетело, нет у него такого текста сообщения об ошибке...

PHP не создаёт запись MySQL, ошибки не выводит, что делать?

$create_table = mysqli_query($connect, "INSERT INTO `users`(`id`, `username`, `email`, `password`, `plan`, `banned`, `avatar`, `subscribers`, `status`, `used_plan`) VALUES (NULL, '$username', '$email', '$password', 3, 'no', '$rand1', 0, 'surfer', 3)");

Жадность, жадность.

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

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

даже ошибку при выполнении не выводит!
error.log пустой

А включи на чутка General Log и посмотри, что пых шлёт на сервер. Может, твой запрос-то до муськи даже не добирается...

Как обойти проблему "LOAD DATA LOCAL INFILE file request rejected due to restrictions on access"?

Andrew_Novikov,

Вот, что я нашел: 'MySQL пытается прочитать файлы параметров в указанном выше порядке.

Во-первых, тут имеется в виду именно сервер MySQL, а не клиент mysql.exe. То, что получит клиент, берётся из секции [client] конфигурационного файла.
Во-вторых, список и порядок загрузки файлов конфигурации зависит от ОС. Подробнее тут: Using Option Files.
В третьих, файл конфигурации может быть указан в командной строке. Такой файл обрабатывается последним (или, если задано соотв. опцией - единственным).
В четвёртых, отдельные параметры могут указываться и в командной строке - тогда они имеют приоритет перед любыми файлами конфигурации. Но при наличии одноимённого параметра для сервера и для клиента то, что передано в опциях командной строки, однозначно воспринимается как серверная настройка.

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

Как правильно реализовать систему групп у пользователя?

BasiC2k, Будет та же хрень, что и с CSV - фуллскан. А multivalued indices пока использовать нельзя - бага там серьёзная.

KYOCERA ошибка при сканировании. как решить проблему?

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

Каким образом можно быстро перенести базу данных?

Имеется дамп старой
Хочу перенести данные из старой базы в новую базу.

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

Каким образом можно быстро перенести базу данных?

Adamos, миграцию на основе дампа? а оно точно это умеет?

Как итерировать полученные данные из запроса select?

Давайте, Вы опишете собственно задачу, а не только свою попытку её решить...

Как обойти проблему "LOAD DATA LOCAL INFILE file request rejected due to restrictions on access"?

Клиент может иметь свой собственный файл настроек, которые накладываются поверх переданных сервером настроек сессии. Так что надо разрешить local_infile и там.

Дмитрий, данная глобальная установка относится только к серверной стороне, и там всё нормально, потому как в CLI запрос работает. Проблема именно в клиентской настройке.