имеем табличку....много столбцов, одно из них varchar(10) в нем либо пустая строка, либо true запрос Код (Text): SELECT * FROM `table` WHERE `field` = 'true' вернет ноль строк....с какого перепугу??? Код (Text): SELECT * FROM `table` WHERE `field` LIKE 'true' то же ноль.... Код (Text): SELECT * FROM `table` WHERE `field` LIKE '%true%' и только так оно что то найдет.... Оно строку true как то извращенно понимает??? Добавлено спустя 6 минут 20 секунд: твою ж мать!!! Код (Text): var_dump ["field"]=> string(5) "true " там пробел лежит ((( Код (Text): SELECT * FROM `table` WHERE `field` = 'true ' но так то же ноль (
ищет подстроку true внутри строки. и находит. а остальные конструкции требуют четкого следования четырех байт - t,r,u,e в строке и только их. и не находят потому что их там нет. если сделать select hex(field) то нам нужно увидеть 74727565 чтоб там было то что попадает под = 'true' и like='true'. но скорее всего будут другие значения.
Соответственно тип ENUM к вашим услугам. Если же там может быть true или любое осмысленное значение без ограничений, то таблица с неправильной структурой.
Не факт, - скорее "пробельный" символ. Надо использовать trim() при вставке в БД. Причём для функции прописать коды всех пробельных символов, в т.ч. и 0D. (если UNICODE, то там сложнее - одним trim не отделаться)
Господа, речь не о структуре таблиц и типе полей понятное дело что неправильная, данные лежат не так и т.д....это все дело сто сорок пятое...понимаете??? Вот вы приходите на новую работу, 10 лет эта база вот так висела, все работает, все так привыкли, вы в первый день заявляете база говно, все к фигам переделывать, остановите работу конторы на трое суток я буду структуру базу переделывать, потому что считаю что там говно... резонный вопрос, парень!! акстись!!! оно 10 лет работает и все всех устраивает кроме тебя умника блеать!!! Тетя Таня 10 лет складывает данные с переносом строки в бд, как ЕЁ в ЕЁ 69 лет мы переучим??? как то так.... вопрос собна решен, "лайком" выберем, там не много...
Ну конечно. Универсальное решение для хранения истины в бд. Добавлено спустя 3 минуты 55 секунд: Ну уж не всю структуру бд менять. Один тип в таблице выбрать человеческий чтобы последователи не спотыкались о те же камни что вы. Делается двумя запросами и максимум поправкой 1 модельки. Всёравно же будете проходить таблицу и убирать пробелы у значений "true ". Вопрос не решён а отложен ещё на год... .
конечно нет, там обычный файл бла.бла.бла.бла перевод строки бла.бла.бла.бла перевод строки бла.бла.бла.бла вот оно его хавает и перегоняет в БД..вместе с переводом )
А так не работает? Код (Text): LOAD DATA INFILE ... INTO TABLE t (@var) SET t.flag = if(@var = 'true', true, false);
что-то Дмитрий уже порывался в базе уменьшать на 1 символ с помощью пхп-скрипта. видимо проблема нелеченного символа \r уже проявлялась. а всего делов перед импортом обрабатывать файл dos2unix
по умолчанию считается, что строка заканчивается по юниксовски. ты можешь либо приводить исходные файлы к стандарту (я бы так и делал), либо заточить импорт на досовский стандарт. LOAD DATA LOCAL INFILE … LINES TERMINATED BY '\r\n' тогда лишний \r не будут попадать в таблицу. не надо, блин, нашивать заплатки на заплатки. это косяк и его надо лечить. Код (Text): UPDATE `table` SET `field` = TRIM(TRAILING '\r' FROM `field`)