Freeman
Новичок
Выборка из таблицы LIKE (русские буквы)
Требуется сделать поиск по таблице вида
id | title (varchar 255, cp1251_bin) | text (text, cp1251_bin)
При выборе из таблицы запросом WHERE. LIKE ‘русские буквы’ phpMyAdmin выдает ошибку
#1267 — Illegal mix of collations (cp1251_bin,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation ‘like’
В скрипте выполняю этот запрос (mysql_query()) — вообще ничего не возвращает (вернее возвращает ошибку)
Как такое победить. Причем для некторых слов поиск проходит и выдается результат, но неполный (не все записи, имеющие совпадение с введенным словом).
P.S.: PHP 4.3.6, MySQL 4.1, Win2000 Server
P.S.S.: SET NAMES ‘cp1251’ и SET CHARACTER SET ‘cp1251’ сделал.
Апельсин
Оранжевое создание
Freeman
Новичок
collation_connection utf8_general_ci
collation_database cp1251_general_ci
collation_server latin1_swedish_ci
Как я понимаю, все кодировки надо привести к единому «стандарту». Можно это сделать запросами или надо обязательно лезть в конфиги MySQL?
Апельсин
Оранжевое создание
ну так ничего удивительного в ошибке нет.
если set names в phpmyadmin делал, значит он каждый раз заново открывает соединение при выполнении запроса.
смотри может в конфигах самого phpmyadmin настроить как-то можно.
Freeman
Новичок
Profic
just Profic (PHP5 BetaTeam)
1) вопрос, зачем cp1251_bin если есть сp1251_general_ci, bin букву ё будет в начало списка загонять при сортировке (если это конечно важно 
если ничего не хочется трогать , то можно написать [sql]WHERE CONVERT(field, utf8_general_ci) LIKE ‘бла-бла'[/sql] (или где-то так) и таким же образом переделать все запросы
или скормить phpMyAdmin-у конструкцию
[sql]
SET NAMES cp1251_bin;
SELECT . WHERE field LIKE ‘бла-бла’;
[/sql]
за один раз, но этот вариант может не работать.
ADD: не будет работать. еще это ‘бла-бла’ тоже нужно из utf в cp1251 сконвертировать CONVERT()-ом
2) я не понял — в качестве интерфейса используется phpMyAdmin или что-то самописное?
если самописное, то я на такую проблему обычно не обращаю внимание — тестовые запросы изменяю в соответствии (1)
Freeman
Новичок
Да, использую свой (вернее, не свой, к сожалению) скрипт. Спасибо за ответ, буду переделывать исходники
Что-то у меня ошибочка выдается на utf8_general_ci. А если заглянуть в справочное руководство, то там говорится следующее:
где аргумент type представляет один из типов:
BINARY
DATE
DATETIME
SIGNED
TIME
UNSIGNED
Блин, ведь должна же быть в mysql функция «приведения кодировок».
И еще такой вопрос: создение полнотекстового индекса FULLTEXT поможет ускорить поиск? Или я неверно понимаю назначение этого индекса? Сама база пока небольшая (порядка 500 статей по 5-6 страниц в среднем).
I have successfully implemented Ignited-Datatables. However, while searching with database when typing «non-latin» characters like «İ,ş,ğ. «
POST 500 (Internal Server Error)
%Ä°% part changes according to the non-latin character you typed.
Any idea for solving this?
5 Answers 5
I figured out the problem. It seems it is DATETIME fields that causes the problem.
gives error for Illegal mix of collations for operation ‘like’ . When I remove LIKE partials DATETIME fields, there are no error any more. I hope this helps.
Try the following:
Also you can refer to MySQL _bin and binary Collations for more information on utf8_bin :
Nonbinary strings (as stored in the CHAR, VARCHAR, and TEXT data types) have a character set and collation. A given character set can have several collations, each of which defines a particular sorting and comparison order for the characters in the set. One of these is the binary collation for the character set, indicated by a _bin suffix in the collation name. For example, latin1 and utf8 have binary collations named latin1_bin and utf8_bin.
 |
| Дата последнего входа: | более года назад |
Столкнулся с проблемой несовпадения collations в БД. Интернет подобным просто кишит. Видал подобная проблема была озвучена на форумах, и был дан комплект SQL запросов напрямую к СУБД для её решения.
У меня возникла ошибка вида
Вот шаблон к ее решению
1. Удаляем модуль поиск, включая таблицы и статистику.
2. Устанавливаем модуль вновь.
Подключаемся к СУБД с достаточными правами на модификацию таблиц в конкретной БД.
Я определил себе следующий пакет запросов