Выборка текстового поля по маске (like, matches)
bukreev
Помогите разобраться, при переходе с Windows NT 4.0 Server на Windows
2000 Server SR2 возникла следующая проблема, при выборке из
символьного поля (nvarchar(20)) по маске в некоторых таблицах
происходит такая ситуация:
Значение поля например - '26306923000013'
select from <tab_name> where <col_name> like '2630%' - не выдает
ничего, в то время как
select from <tab_name> where <col_name> like '%2630%' - выдает все
нормально.
Если использовать matches - та же ситуация. Создаётся впечатление, что
в начале строкового значения есть какой-то служебный символ или что-то
в этом роде, но когда я вичисляю его длину select length(col_name), то
выдает длину 14, что соответствует количеству символов. Причем эта
ситуация возникает не во всех таблицах, где есть аналогичные поля, из
некоторых все выбирается нормально. Хотя тип поля везде одинаковый.
Может это баг Информикса? Или я что-то неправильно сделал при импорте
данных. А делал я как обычно при помощи dbexport/dbimport.
На NT 4.0 такой проблемы вообще не было. Помогите пожалуйста!
Использую IDS 7.31.TC8.
Влад.
Igor Zavgorodny
> Привет всем!
> Значение поля например - '26306923000013'
> select from <tab_name> where <col_name> like '2630%' - не выдает
> ничего, в то время как
> select from <tab_name> where <col_name> like '%2630%' - выдает все
> нормально.
select from <tab_name> where <col_name> like '2630%%'
и такое:
select from <tab_name> where <col_name>[1,4]='2630'
> Может это баг Информикса? Или я что-то неправильно сделал при импорте
> данных. А делал я как обычно при помощи dbexport/dbimport.
> На NT 4.0 такой проблемы вообще не было. Помогите пожалуйста!
>
> Использую IDS 7.31.TC8.
>
Очень возможно, что это баг Informix-a, по крайней мере на 9-ке подобная
проблема есть (по рой архивы конфы на предмет Matches). Возможно
проблема решится если поле сделать типа varchar(20).
Regards, Igor.
Vasyl Shulzhenko
"bukreev" <vbuk...@smtp.ru> wrote in message
news:d578e270.0209...@posting.google.com...
> Привет всем!
>
> Помогите разобраться, при переходе с Windows NT 4.0 Server на Windows
> 2000 Server SR2 возникла следующая проблема, при выборке из
> символьного поля (nvarchar(20)) по маске в некоторых таблицах
Рекомендую сделать поле фиксированным (char(20)). За счет varchar много не
сэкономишь на этой длине, а проблем с индексами и поиском можешь добавить. И
если значения в столбце только числовые (нет локализованного текста), то
лучше не используйте национальные текстовые типы (типа nchar).
> происходит такая ситуация:
>
> Значение поля например - '26306923000013'
> select from <tab_name> where <col_name> like '2630%' - не выдает
> ничего, в то время как
> select from <tab_name> where <col_name> like '%2630%' - выдает все
> нормально.
> Если использовать matches - та же ситуация. Создаётся впечатление, что
> в начале строкового значения есть какой-то служебный символ или что-то
> в этом роде, но когда я вичисляю его длину select length(col_name), то
Строго говоря, в varchar в начале таки есть служебный байт (длина поля), но
это не должно мешать функциям поиска (если они реализованы без багов).
А баги, как уже отмечал Игорь (да и в FAQ-е конфы об этом есть) на эту тему
были неоднократно.
> выдает длину 14, что соответствует количеству символов. Причем эта
> ситуация возникает не во всех таблицах, где есть аналогичные поля, из
> некоторых все выбирается нормально. Хотя тип поля везде одинаковый.
> Может это баг Информикса? Или я что-то неправильно сделал при импорте
> данных. А делал я как обычно при помощи dbexport/dbimport.
А локали изменялись при переходе ?
> На NT 4.0 такой проблемы вообще не было. Помогите пожалуйста!
>
> Использую IDS 7.31.TC8.
А какая версия использовалась на NT 4.0 ? Если другая, то это проблема
Информикса, а не перехода на другую ОС.
bukreev
> bukreev wrote:
> > Привет всем!
> > Значение поля например - '26306923000013'
> > select from <tab_name> where <col_name> like '2630%' - не выдает
> > ничего, в то время как
> > select from <tab_name> where <col_name> like '%2630%' - выдает все
> > нормально.
> Что выдает например такое:
> select from <tab_name> where <col_name> like '2630%%'
> и такое:
> select from <tab_name> where <col_name>[1,4]='2630'
>
> > Может это баг Информикса? Или я что-то неправильно сделал при импорте
> > данных. А делал я как обычно при помощи dbexport/dbimport.
> > На NT 4.0 такой проблемы вообще не было. Помогите пожалуйста!
> >
> > Использую IDS 7.31.TC8.
> >
>
> Очень возможно, что это баг Informix-a, по крайней мере на 9-ке подобная
Действительно это баг, я нарыл в конфах:
122587 MATCHES OR LIKE ON INDEX WITH NCHAR OR NVARCHAR FIELD GIVES WRONG
RESULT
bukreev
> "bukreev" <vbuk...@smtp.ru> wrote in message
> news:d578e270.0209...@posting.google.com...
> > Привет всем!
> >
> > Помогите разобраться, при переходе с Windows NT 4.0 Server на Windows
> > 2000 Server SR2 возникла следующая проблема, при выборке из
> > символьного поля (nvarchar(20)) по маске в некоторых таблицах
>
> Рекомендую сделать поле фиксированным (char(20)). За счет varchar много не
> сэкономишь на этой длине, а проблем с индексами и поиском можешь добавить. И
> если значения в столбце только числовые (нет локализованного текста), то
> лучше не используйте национальные текстовые типы (типа nchar).
>
каким-угодно, а также присутствуют не только цифры.
> > происходит такая ситуация:
> >
> > Значение поля например - '26306923000013'
> > select from <tab_name> where <col_name> like '2630%' - не выдает
> > ничего, в то время как
> > select from <tab_name> where <col_name> like '%2630%' - выдает все
> > нормально.
> > Если использовать matches - та же ситуация. Создаётся впечатление, что
> > в начале строкового значения есть какой-то служебный символ или что-то
> > в этом роде, но когда я вичисляю его длину select length(col_name), то
>
> Строго говоря, в varchar в начале таки есть служебный байт (длина поля), но
> это не должно мешать функциям поиска (если они реализованы без багов).
> А баги, как уже отмечал Игорь (да и в FAQ-е конфы об этом есть) на эту тему
> были неоднократно.
>
> > выдает длину 14, что соответствует количеству символов. Причем эта
> > ситуация возникает не во всех таблицах, где есть аналогичные поля, из
> > некоторых все выбирается нормально. Хотя тип поля везде одинаковый.
> > Может это баг Информикса? Или я что-то неправильно сделал при импорте
> > данных. А делал я как обычно при помощи dbexport/dbimport.
>
> А локали изменялись при переходе ?
Не изменялись.
>
> > На NT 4.0 такой проблемы вообще не было. Помогите пожалуйста!
> >
> > Использую IDS 7.31.TC8.
>
> А какая версия использовалась на NT 4.0 ? Если другая, то это проблема
> Информикса, а не перехода на другую ОС.
Все абсолютно то же самое, изменилась только ОС.
Всем большое спасибо, проблему решил с помощью Игоря, см. предю мой
пост.
Журавлев Денис
не
> > сэкономишь на этой длине, а проблем с индексами и поиском можешь
добавить. И
> > если значения в столбце только числовые (нет локализованного текста), то
> > лучше не используйте национальные текстовые типы (типа nchar).
> >
> Фиксированным сдклать нельза, так как это банк. счет, а он может быть
> каким-угодно, а также присутствуют не только цифры.
Ну ясен пень, если он может быть каким угодно, то надо ограничить его 20
символами. Сэкономил при обычной длине счета 15 символов, целых 3 байта?
Зато сколько интересных багов можно огрести c IPAT.
Я считаю можно (нужно) использовать тип char(varchar) вместо nchar(nvarchar)
даже если в поле есть национальные символы, если по этому полю не требуется
сортировка (cmp) в порядке следования символов в национальном алфавите, и не
будут применятся функции типа APPER, т.к. сравнение таких строк ускоряется
сильно, у меня индексы например строятся в 2-4 раза быстрее.
Журавлев Денис.
Vasyl Shulzhenko
"Журавлев Денис" <z...@chspz.ru> wrote in message
news:alsj1p$pu9$1...@news.lucky.net...
> > > Рекомендую сделать поле фиксированным (char(20)). За счет varchar
много
> не
> > > сэкономишь на этой длине, а проблем с индексами и поиском можешь
> добавить. И
> > > если значения в столбце только числовые (нет локализованного текста),
то
> > > лучше не используйте национальные текстовые типы (типа nchar).
> > >
> > Фиксированным сдклать нельза, так как это банк. счет, а он может быть
> > каким-угодно, а также присутствуют не только цифры.
Но ты ограничил его до 20 ? varchar(20). Так почему нельзя сделать char(20)
? Речь ведь именно об этом.
> Ну ясен пень, если он может быть каким угодно, то надо ограничить его 20
> символами. Сэкономил при обычной длине счета 15 символов, целых 3 байта?
> Зато сколько интересных багов можно огрести c IPAT.
>
> Я считаю можно (нужно) использовать тип char(varchar) вместо
nchar(nvarchar)
> даже если в поле есть национальные символы, если по этому полю не
требуется
> сортировка (cmp) в порядке следования символов в национальном алфавите, и
не
> будут применятся функции типа APPER, т.к. сравнение таких строк ускоряется
> сильно, у меня индексы например строятся в 2-4 раза быстрее.
Полностью согласен и готов подписаться :)
Причем индексы не только быстрее строятся, но и быстрее работают.