Всем привет! Помогите с пожалуйста с нубским вопросом. В такой конструкции

ключ нормально используется или нет?

DATA lt_tab TYPE SORTED TABLE OF sometype WITH NON-UNIQUE KEY field1 field2

LOOP AT lt_tab ASSIGNING FIELD-SYMBOL(<ls_tab>) USING KEY primary_key
WHERE field1 = var1
AND field2(2) = var2(2)

Если синт анализатор пропустил, то да

Это ты про компилятор при активации? Он так правильно называется? Но как быть уверенным что ключи используется?

Да, про него Используются. Можешь написать тест, в котором будешь читать здоровую таблу без указания ключа. Разницу будет видно

Anton
Что то судя по SAT оптимизированный WHERE не работ...

Нет. Ты не понял. Первый пример для теста твой. Второй тоже твой, но убери из таблы ключ. Поля поиска оставь те же

без ключа оставить? Тогда же фул скан будет... Я хочу что бы вот это работало... https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-us/abenitab_where_optimization.htm Есть убрать USING KEY ** то конечно работает. Но я хочу что бы он быстро работал, а не перебором...

В where надо указать все 4 ключевых поле, а не один при using key. По другому не будет работать.

Это не так. Достаточно писать левые. Нельзя использовать вторичный ключ в лупе, если он не оптимизированный. Компилятор ругнется. При первых двух не ругается.

В сортировочной можно хоть одно поле использовать. При стандартной, нужно все 4 поля использовать.

А зачем в лупе по сортировочной таблице using key? Он и так по ключам пойдет. Или очень хочется по первичному пойти? Мне кажется это какое то извращение. Надо использовать по назначение все что дается.

Primary_key лишний, я согласен. Мне нужен оптимизированный where.

Будет. Про это есть в хелпе. Поля с начала ключа и все работает. И на части полей это тоже распространяется

Нет, я проверил. Если я во втором случае мандант раскоиентирую компилятор не ругается

Так тебе ж пример надо, что бы скорость сравнить.

Тут не уникальные сортировочный вторичный ключ. В хелпе вроде сортировочный используется STANDARD TABLE OF line                WITH UNIQUE SORTED KEY key Но это надо проверять в живую в тестовой программе. Удачи в играх на ночь!

Уник не Уник роли не играет. Коллега @vlad_kyu недавно так же чекал)

Синтанализатор это пропускает, а вот работает ли реально - не проверял

В общем я проверил optimizable where не работает с field2(2). При этом компилятор пропускает такое выражение даже со STANDART WITH SORTED KEY. А по факту идет фулскан. При этом я почти уверен, что месяц назад field2(2) работал нормально, может есть параметр какой на AS? :)

Код в студию

Тестовый код не писал, сорян. Результат на боевой программе смотрел через SAT.

Несчитова.