Статистику можно посмотреть в плане выполнения запроса. (транз. ST05 - Explain - Analyze (F7) )

Добрый день.
Если хотите выбрать соответствующие записи из этой таблицы, то единственный способ выбора по чаровым полям это так
с '000000001' по '000000003', вот тогда должен выбрать правильно.

Чтобы не заморачиваться с ведущими нулями есть ФМ
CONVERSION_EXIT_ALPHA_OUTPUT/CONVERSION_EXIT_ALPHA_INPUT

из всей темы можно сделать вывод:
если таблица не поддается изменению, а в доменах элементов данных, которые используются в полях таблицы, по которым производится выборка (блин, страшная формулировка получилась ), не указана подпрограмма преобразования, то при выборке руками добавлять лидирующие нули (если тип поля CHAR, естественно).

если таблица поддается изменению (например, Z-овская), то обязательно прописывать подпрограмму преобразования для полей CHAR. Если же поле всегда состоит из цифр, вообще использовать тип NUMC.

Во-первых, программа преобразования определяется на уровне домена, а не в таблице. Во-вторых, эти преобразования на таблицу и на SQL-запросы никак не влияют.

я в курсе, где определяется подпрограмма преобразования, прочитайте внимательнее мое сообщение (хотя слишком запутано написал).
ну а как же не влияют?? через SE11 при отсутствии подпрограммы в домене если писать без лидирующих нулей - выберется не то, что ожидалось. а SE11 - она генерирует отчет с именем /db... (что-то такое), а экран выбора - это SELECT-OPTIONS, нули добавляются автоматически, соответственно выражение field IN so в запросе работает "правильно", вот так и влияет..
ну это так, в пример...

А так и не влияют - преобразование выполняется _только_ в момент передачи значения _с экрана в ABAP_, так-же как и приведение к верхнему регистру (при отсутствии соответствующей опции в домене). Внутри ABAP-а работа всегда идёт в внутреннем представлении без каких-либо преобразований (преобразования типов тут не в счёт)..