Где проблема с рус.кодировкой

← →
bumper (2006-07-27 01:14) [0]

Например...
Есть таблица KATULIC c названиями улиц:
ID Name
1 Пушкинская
2 Лермонтова
3 Ломоносова
4 Ленина
и т.п. Таблица имеет индекс по полю NAME.

в других табоицах используются lookup-поля для доступа к названию улицы. При создании базы использовал WIN1251.
В IBDataBase1.Params перед коннектом написал: lc_ctype=WIN1251, не уверен что так надо, но где-то видел :)

В DBGridEh в соотв. колонке, или в DBLookupComboboxEh есть выпадающий список для ввода названия улицы.

Собственно проблема: При нажатии на буковку выпадает список с названиями. Если там англицкие названия, проблем никаких и регистр побоку, но если мне надо улицу Ломоносова, то нажатие маленькой "л" ни к чему не приводит, если с шифтом, то позиционируется на букву "Л". Но следующую надо тоже писать в верхнем регистре и достаточно быстро, можно успеть набрать 3 символа - дальше позиционировние не происходит. Если в базе все русские большие и на клавиатуре набирать большие - тож ок......
Короче, надо чтоб и в русских символах можно было плевать на регистр.
Кого здесь винить: себя, FB или EhLib?
Поясните кто что может по сабжу.

← →
atruhin © (2006-07-27 08:45) [1]

> Где проблема с рус.кодировкой

Нет такой проблеммы, ни там, ни там :)

Читать до полного просвятления, там все написано:

http://www.ibase.ru/devinfo/ibrusfaq.htm

← →
PEAKTOP © (2006-07-27 11:00) [2]

Те таблицу-справочник "KATULIC" надо в верхнем регистре выбирать.
Я, например, вообще в базах на каждую таблицу справочник вешаю триггеры, чтобы записи хранились в верхнем регистре, типа
CREATE TRIGGER TRIG$MYTALE_BI_000 FOR MYTABLE ACTIVE BEFORE INSERT POSITION 0 AS BEGIN NEW.NAME = UPPER(NEW.NAME); END
Тогда и ищет быстрее, особенно если хочется сделать наворот в стиле "1С:Предприятие", когда в справочнике нажимаешь пробел, а затем набираешь буквы. По мере набора курсор НД позиционируется на первой подходящей записи, начинающейся на эту последовательность символов.

← →
bumper (2006-07-27 14:59) [3]

> Читать до полного просвятления, там все написано:

... читаю, надеюсь просветлит :)

> Я, например, вообще в базах на каждую таблицу справочник
> вешаю триггеры, чтобы записи хранились в верхнем регистре,
> типа

Пробовал, Не совсем эстетично выглядят на экране все большие.....тем более что адрес формируется во многих местах из этих улиц....
Можно извратов сделать и обратно преобразовывать - для отображения, чтоб первая большая, остальные малелькие, но тоже не выход:
ул. Карла Маркса, пер.Фридриха Энгельса, пл.Советских моряков и т.п. + есть ещё аббревиатуры ГОБК, МОПРа - они не вписываются в общую картину....

Вобщем, раз нет проблемы в софте, ищу что упустил......

← →
bumper (2006-07-27 15:09) [4]

Всё товарищи :), проблема отпала и была как всегда во мне :))))))
Параметры конекта, в том числе и кодировку, прописывал в IBDataBase.Params в дизайнере, а и упустил, что они у меня в рантайме из ини-файла берутся....:)

← →
atruhin © (2006-07-27 15:34) [5]

> [2] PEAKTOP © (27.07.06 11:00)

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

> atruhin © (27.07.06 15:34) [5]
> FB умеет сортировать независимо от регистра, скорость при этом не снижается.
>

А мне не сотрировать надо. В 90% случаев приходится пользоваться конструкцией
..... IBQuery1.SQL.Text := "SELECT ... FROM MYTABLE TB WHERE (TB.NAME LIKE ""%" + AnsiUpperCase(TextToFind) + "%"") ORDER BY TB.NAME "; ....
А между запросами
b>SELECT ... FROM MYTABLE TB WHERE (TB.NAME LIKE ""%" + AnsiUpperCase(TextToFind) + "%"") ORDER BY TB.NAME
и
b>SELECT ... FROM MYTABLE TB WHERE (UPPER(TB.NAME) LIKE ""%" + AnsiUpperCase(TextToFind) + "%"") ORDER BY TB.NAME
две большие разницы по скрости на ~40 000 позиций с справочнике ТМЦ.

А так: :)
SELECT ... FROM MYTABLE TB WHERE (TB.NAME COLLATE PXW_CYRL LIKE ""%" + AnsiUpperCase(TextToFind) + "%"") ORDER BY TB.NAME

Где проблема с рус.кодировкой - в FB 1.5.3 или EhLib 3.6? Найти похожие ветки