Работа в отчётах с параметром SELECT-OPTIONS проста.
Сначала определяем:
select-options: s_anln1 for anla-anln1.
Потом используем:
select * from anla into table gt_report where anln1 in s_anln1.
Всё просто на первый взгляд. При таком коде внутри Open SQL происходит простая работа: OpenSQL трансформируется в NativeSQL, а там подобной конструкции нет. Поэтому фактический запрос превращается приблизительно в следующее:
select * from dbchema.anla where anln1 = ‘1’ or anln1 = ‘2’ or anln1 = ‘3’;
И если бы забьём очень много значений в поле выбора, то длина получающегося в результате SQL запроса будет расти линейно. Именно где-то тут я встретился с узким местом, в котором меня стукнули по носу динамической ошибкой DBIF_RSQL_INVALID_RSQL. Интересно, а почему не SAPSQL_STMNT_TOO_LARGE?
В моём случае это примерно 9980 значений типа ANLN1. Это эмпирическое число видимо будет разниться от системе к системе, от используемого типа данных и прочих условий. И как его гарантированно предсказать в общем случае?
Есть в недавней игре Saints Row: Gat Out of Hell одно достижение: десять раз стукнуться головой о потолок.
Как быть?
В моём случае я решил, что пользователю не следует выдумывать себе сценарии, в которых необходимо вводить десять тысяч значений в поле выбора. Ибо нефиг. Для красоты можно разве что поставить проверку на экране выбора, чтобы в эти очень редкие моменты красиво выругаться. Динамическая ошибка – это не красиво.
