Update внутри SELECT..ENDSELECT

Boozila

Привет,

В стандартной большой (в продуктиве - миллионы) таблице есть z-поля.
Надо во всех записях их населить на основании некоторых вычислений.
Делаем SELECT..ENDSELECT с указанием PACKAGE SIZE:

Code:

SELECT ... INTO TABLE it PACKAGE SIZE 1000 WHERE <условие не по z-полям>.
 
  loop at it.
  "Вычисляем/заполняем z-поля
  endloop.

  loop at it.
    UPDATE..SET Z1 = ... WHERE ...
  endloop.
  COMMIT WORK. " То есть COMMIT для очередных 1000 записей

ENDSELECT.

Валимся в дамп после выполнения первой итерации SELECT..ENDSELECT, т.е. в момент когда

Code:

SELECT ... INTO TABLE it PACKAGE SIZE 1000 WHERE (условие не по z-полям).

выполняется во второй раз.
Дамп такой:

Code:

Runtime Errors         DBIF_RSQL_INVALID_CURSOR
Except.                CX_SY_OPEN_SQL_DB
 ...
Possible causes in the application program:
While a read process from a database cursor is taking place
(within a loop SELECT/LOOP/EXEC SQL or before a FETCH command),
one of the following statements is used:
 
- MESSAGE (apart from MESSAGE S...)
- COMMIT WORK
- ROLLBACK WORK
- BREAK-POINT
- WAIT
- CALL FUNCTION ... DESTINATION (synchronous RFC)
- CALL FUNCTION ... STARTING NEW TASK
- RECEIVE RESULTS
- CALL DIALOG
- CALL SELECTION-SCREEN
- CALL TRANSACTION
- CALL SCREEN, or any other statement that results in the display of a new screen

Действительно, COMMIT внутри цикла есть.
Вопрос - если я его, к примеру, уберу чтобы избежать дампа - в какой момент система сама его применит?
Случайно не после обработки всех миллионов записей? Если так - видимо можно ожидать что ресурсов на транзакцию такого размера может не хватить? (в системе разработки записей мало, эксперимент не поставишь)

Или может следует организовать обновление иначе? Типа - применить курсор...
На всякий случай - речь об ECC6, MS SQL.

Спасибо заранее

Удав

Для обновления полей больших таблиц я применял следующий алгоритм:
1.Выбирал ключи записей, которые нужно изменить
2.В цикле для каждой записи отдельно выбирал все данные из таблицы для обновления, заполнял Z-поля и добавлял во 2-ю внутреннюю таблицу, через каждые n-ого записей (1000) выполнял UPDATE из 2-й внутренней таблицы.
3.Очищал 2-ю внутреннюю таблицу и делал COMMIT
После цикла апдейтил оставшиеся записи.

imp

Boozila написал(а):

Или может следует организовать обновление иначе? Типа - применить курсор...

Можно через OPEN CURSOR WITH HOLD:
http://help.sap.com/abapdocu_70/en/ABAPOPEN_CURSOR.htm

Только коммит после обработки очередной порции записей нужно будет делать не через оператор COMMIT WORK, а через ФМ 'DB_COMMIT', тогда курсор не закроется.

Boozila

Вот спасибо.
Оба подхода выглядят убедительно.
Думаю - начну со 2-го, т.к. переделывать ничего не надо.

Правила форума

Update внутри SELECT..ENDSELECT

Кто сейчас на конференции