Лимит массового сбора с немедленным выполнением

Для работы с миллионами записей я хочу установить ограничение в 500, но следующий код выдает ошибку. Отчет об ошибке: ORA-06550: строка 6, столбец 49: PLS-00103: обнаружен символ «LIMIT» при ожидании одного из следующих событий:

DECLARE
    TYPE EMP_T IS TABLE OF NUMBER;
    EMP_ID EMP_T;
    QRY VARCHAR2(4000):='SELECT EMPLOYEE_ID FROM EMPLOYEES';
begin   
    execute immediate QRY bulk collect into EMP_ID LIMIT 500;
END;

oracle collect bulk execute-immediate
person PTK    schedule 22.02.2017    source источник
comment
Возможный дубликат массового сбора и немедленного выполнения в Oracle   -  person Maheswaran Ravisankar    schedule 22.02.2017
comment
LIMIT 500. Я думаю, вы не понимаете, почему используется LIMIT и какой лучший LIMIT вы можете установить для массового сбора. LIMIT просто не является числом счетчиков строк. Если вы хотите, чтобы счетчик строк использовал его в своем динамическом запросе, чтобы ограничить строку. Прочитайте это . stackoverflow .com/questions/38659739/   -  person XING    schedule 22.02.2017

Ответы (1)


arrow_upward
0
arrow_downward

Это не способ использовать предложение LIMIT. Я думаю, что вы не можете использовать предложение LIMIT в BULK COLLECT с EXECUTE IMMEDIATE. ОГРАНИЧЕНИЕ МАССОВОГО СБОРА в НЕМЕДЛЕННОМ ВЫПОЛНЕНИИ

Пример:

DECLARE
    TYPE EMP_T IS TABLE OF NUMBER;
    EMP_ID EMP_T;
    CURSOR c_data IS SELECT empid FROM EMPLOYEE;
begin   
OPEN c_data;
  LOOP
    FETCH c_data
    BULK COLLECT INTO EMP_ID LIMIT 100;
    EXIT WHEN EMP_ID.count = 0;

    -- Process contents of collection here.
    DBMS_OUTPUT.put_line(EMP_ID.count || ' rows');
  END LOOP;
  CLOSE c_data;
END;
/
person atokpas    schedule 22.02.2017
comment
Я не могу использовать курсор, так как мой запрос не является статическим. Запрос создается динамически, а затем используется для немедленного выполнения. - person PTK; 22.02.2017
comment
Если вы используете Oracle 12c, вы можете использовать предложение ограничения строк, что-то вроде FETCH FIRST 500 ROWS. - person BobC; 22.02.2017