Подскажите, как заставить оператор like вести поиск без учёта регистра?

никак. Для этого у САП в ряде таблиц есть поля-дублеры. Там символы хранятся в верхнем регистре.

жаль
Просто дублировать в верхнем регистре какраз и не хотелось, таблица и так неприличного размера получилась.

А средствами движка БД (oracle) никак в этом случае не соптимизировать? Нужны собственно только значения первичного ключа (цифровой ID), по условию LIKE длинное_текстовое_поле.

Попробуйте Native SQL - там можно использовать SQL - словарь Oracle.
Если не ошибаюсь, там есть функция UPPER

попробовал - работает быстро но неправильно. Похоже САП изобрёл какуюто свою уникальную кодировку символов - если затребовать средствами native sql выражения типа UPPER(поле) LOWER(поле), то там такие чудеса с некоторыми русскими буквами происходят.

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

Ну вместо преобразования регистра строк, можно воспользоваться REGEX_SUBSTR и програмно переводить LIKE что-то в регулярное выражение (для Oracle).
Только мне не очень нравится идея использования специфичных фич конкретной СУБД.

ИМХО, вариант от САПа с дублированием столбцов таблицы - самый нормальный при текущей реализации OpenSQL.

А еще можно сделать комбинации всевозможных вариантов слова. (аб Аб аБ АБ) добавить их в условие со связкой OR . Их всего ничего 2 в степени количества букв, исключая пробелы. Так что, если поле не длинное, то вполне подойдет....

Както не хочется 4 млн.строк (по 64 символа...с перспективой роста так до 10 млн) задваивать. Мне мой вариант понравился больше - база увеличивается всего-лишь на 1/8, ну и плюс добавляется пара функций конверсии (одна при загрузке этого эпического справочника, вторая при вывал результатов LIKE на экран)



Это понятно. Но там скорее всего та-же проблема с кодировками оракла вылезет. Я так толком и не разобрался, почему корёжатся некоторые русские буквы при передаче их через EXEC SQL. Возможно там некую sql-команду указания кодовой страницы надо передавать. Х.з., в общем отказался от идеи напрямую в оракл лезть.

Ну я за вариант САПы, потому как стандарт.
В вашей реализации (которая, безусловно, сильно лучше стандартной) один минус - нужно знать принцип хранения и производить преобразования. Вот если бы САП тоже использовал битовые маски и умел по умолчанию правильно отображать таблицы с таким содержимым...

По кодировкам:
если юникод - то проблемы быть не должно в принципе.
иначе надо приводить к кодировке БД (посмотреть можно путем select * from props$ where name='NLS_CHARACTERSET') в ABAP'е.

а можно для примера 2 столбца привести. Хочется понять, что из себя представляет битовая маска

ну например - текст в таблице БД это поле CHAR64. Добавляем 64-битное поле в таблицу (т.к. в САПе такого нету, делаем два 32битных поля INT4). Пишем нехитрый ФМ, который перебирает посимвольно текст (64 символа), и для каждой позиции, где стоит заглавная буква, взводит соответствующий бит в 64-битовой маске. Потом сохраняем получившуюся маску (2 32битных целых числа) и текст переводим в нижний регистр.

В результате SELECT...LIKE будет искать всегда в нижнем регистре, а чтобы вернуть регистр взад при выводе на экран, пишем ещё один ФМ, который считав битовые маски из БД, опять перебирает посимвольно строку текста, и воостанавливает верхний регистр, если соответствующий бит маски = 1

хорошее решение , спасибо!

Это я так понимаю считывание некой системной ораклиной таблицы (настройки БД хранит) ?
А куда посмотреть, чтоб определить, Юникодная БД или нет (у нас САП 6.20)?

pberezin, так в props$ и посмотреть. я другого способа не знаю. но нужен доступ к БД, конечно. или базис спросить.

Да, действительно, очень остроумно и компактно - маладца.

В качестве дальнейшего усовершенствования можно предложить создать подпрограмму преобразования, чтобы указанные ФМ в случае экранов вызывались автоматом