Как такое может быть?! Быстродействие.

111

Сорри - вы правы, господа :oops:

.
Просто от версии зависит.
Еще в 4.7 работало так, как я говорил.

В более поздних версиях по-вашему.

vga

Витя, может у тебя неявный commit был, когда ты проверял?
В 4.6с rollback work откатывает, без вопросов.

dump

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

Витя, может у тебя неявный commit был, когда ты проверял?
В 4.6с rollback work откатывает, без вопросов.

вполне вероятно - если проверяли в отладчике - то сам режим отладчика вызывает неявные DB commit-ы, при обновлении экрана отладчика - внизу часто можно увидеть сообщение "db commit выполнен системой"

а по поводу вашего случая скажу еще - если у вас такой большой объем данных надо обработать - то кроме того что рекомендуется делать MODIFY пачками - то после каждой пачки надо COMMIT вставлять, иначе у вас REDOLOG переполнится и дамп будет - я уверен что ваша конструкция даже когда по записи работала еще на большом объеме не отрабатывала - иначе даже если по записи MODIFY делать но без COMMIT будет указанный выше дамп.

111

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

Витя, может у тебя неявный commit был, когда ты проверял?
В 4.6с rollback work откатывает, без вопросов.

Нет, проверялось на коде типа

Code:

REPORT  zrollback_test.

DATA: ls_makt TYPE makt .

ls_makt-mandt = sy-mandt .
ls_makt-matnr = 'XXXXXXXXXXXXXXXXXX'.
ls_makt-spras = sy-langu .
ls_makt-maktx = 'Полный левак'.

modify makt FROM ls_makt .
*DELETE makt FROM ls_makt .

*commit WORK .
ROLLBACK WORK .

Результат проверялся по завершению проги, не в отладке (потому что в отладке происходил неявный комит). Настаиваю, что это учитывалось.
Валер, ты уверен? Можешь проверить на старой версии?
Потому что если это был глюк моего сознания – то он был не только у меня, а коллективный (у других 4-х разработчиков тоже).

Дело было так.
Года три назад участвовал в проекте на Нетвивере. Версия ядра не то 6.00, не то 6.40 .
ПМ-ом был ораклоид, очень дотошный товарищ, и заставлял нас все проверять на практике.
Тогда мы открыли для себя много интересного, о чем раньше даже не задумывались.
Например, до этого те же комиты-роллбэки лепили, особо не задумываясь (правда, прямые апдейты и делать приходилось не часто).
И в хелпах, кроме воздействия комитов и роллбэков на LUW’ы (CALL FUNCTION … IN UPDATE TASK), не было ничего больше сказано.
После этого, все критичные обновления БД делал через LUW-ы (понятно, что с комитами-роллбэками).

Мда, век живи, век учись – а помрешь все равно дураком.

Кстати говоря – программа обновления, о которой идет речь выше – делалась не мной, и комит там все равно есть (это уж мне просто поспорить захотелось) .
Так шта, MODIFY по-любому не отрабатывал. Да и UPDATE выдавал SY-SUBRC = 4, хотя в любом случае, адпейтились существующие записи (внутри SELECT…ENDSELECT, ключ не менялся).

vga

Витя, проверил конечно, но думается, ты сомневаешься в фундаментальных вещах.

Версия 4.6с.

Code:

REPORT Z_VGA_TEST NO STANDARD PAGE HEADING .

DATA: l_xblnr TYPE bkpf-xblnr.

DATA: it TYPE TABLE of bkpf WITH HEADER LINE.
SELECT * FROM bkpf INTO TABLE it UP TO 1 ROWS WHERE xblnr NE SPACE.

IF NOT sy-subrc IS INITIAL.
  WRITE: / 'Nothing found, exit.'.
  EXIT.
ENDIF.

READ TABLE it INDEX 1.

l_xblnr = it-xblnr.
WRITE: / 'Before modify, xblnr=', it-xblnr.

it-xblnr = '1234567890'.
MODIFY BKPF FROM TABLE it.
ROLLBACK WORK.

SELECT * FROM bkpf INTO TABLE it
WHERE bukrs = it-bukrs
  AND belnr = it-belnr
  AND gjahr = it-gjahr.

READ TABLE it INDEX 1.
WRITE: / 'After rollback, xblnr=', it-xblnr.

l_xblnr = it-xblnr.

it-xblnr = '1234567890'.
MODIFY BKPF FROM TABLE it.
COMMIT WORK AND WAIT.

SELECT * FROM bkpf INTO TABLE it
WHERE bukrs = it-bukrs
  AND belnr = it-belnr
  AND gjahr = it-gjahr.

WRITE: / 'After commit, xblnr=', it-xblnr.

it-xblnr = l_xblnr.
MODIFY BKPF FROM TABLE it.
COMMIT WORK AND WAIT.
IF sy-subrc IS INITIAL.
 WRITE: / 'Xblnr restored'.
ENDIF.

Result:

Before modify, xblnr= 1111
After rollback, xblnr= 1111
After commit, xblnr= 1234567890
Xblnr restored

sibrin

Я, кончено, не знаю, что было в версии 2.0, но уверен, что всех версиях ROLLBACK WORK откатывал BD LUW. О другом поведении даже подумать страшно.

111

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

Витя, проверил конечно,

Тада фик знает. Наверное, на пенсию мне пора

.

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

но думается, ты сомневаешься в фундаментальных вещах.

Иногда такое бывает, что начнешь сомневаться.

111

sibrin написал:

Я, кончено, не знаю, что было в версии 2.0, но уверен, что всех версиях ROLLBACK WORK откатывал BD LUW. О другом поведении даже подумать страшно.

Откатывал, конечно, всегда, то что через
CALL FUNCTION ... IN UPDATE TASK .

sibrin

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

Откатывал, конечно, всегда, то что через
CALL FUNCTION ... IN UPDATE TASK .

Это SAP LUW. Но и DB LUW тем более!

111

sibrin написал:

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

Откатывал, конечно, всегда, то что через
CALL FUNCTION ... IN UPDATE TASK .

Это SAP LUW. Но и DB LUW тем более!

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

Ну и сами понимаете, как оно бывает - сделаешь определенные выводы, закроешь для себя вопрос, и больше не пересматриваешь.

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

Как такое может быть?! Быстродействие.

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