Дискуссия сводится к лингвистике. Может строго формально и нельзя так говорить, но правильно понять труда не составляет и к путанице не приводит.

Ещё раз: в рамках прикладного процесса после commit work начинается новый SAP LUW. Старый хоть и не завершается, но это всё же граница между двумя SAP LUW.

SAP LUW один, а включает в себя 2 DB LUWа.

Это прямое противоречие с основным принципом любого LUW.
Если sy-subrc <> 0, то первый ztable1 обновится, а ztable2 — нет.
Какой же это unit of work?

Да и в определении SAP LUW чёрным по белым написано: changes are written to the database in a single database LUW.

так в том то и дело что это уже разработчик должен строить программу так чтобы то что должно быть записано вместе попадало в один DB LUW и не допускать чтобы было по-другому - в твоем примере - кто кроме тебя знает что ZTABLE 1 и ZTABLE2 должны обновляться вместе ? системе все равно - может так и надо

конечно это неправильный SAP LUW так как обновления попали в 2 DB LUWа - а не в один

Это опять какое-то новое понятие. Я такого в SAP library не встречал.

ну тут как угодно можно ситуацию выкрутить - если эти две таблицы должны вместе обновляться тогда это не LUW - если нет то LUW

Т.е. правильный SAP LUW состоит из одного DB LUW. Значит в моём примере правильный SAP LUW начинается сразу после create object.
Таким образом получается, что SAP LUW тождественен DB LUW. (Про update bundling мы пока договорились забыть.)

В самом начале я и предложил это называть такой случай вырожденным SAP LUW'ом. Только в SAP Library для такого вырожденного случая термин SAP LUW, по-моему, нигде не применяется. Ещё раз прошу, если есть такое место — подскажите, буду очень признателен.

SAP LUW начинается в начале программы и состоит из двух DB LUWов - только CREATE OBJECT его либо разрушает ( если таблицы должны обновляться вместе ) либо нет ( если синхронное обновление таблиц не критично ).

Цитата взята из книги издательства SAP Press, которую мы здесь обсуждаем. Самый последний рисунок.
Особенности и отладка асинхронных, синхронных и локальных апдейтов.

В SAP Library практически ничего не раскрывается, все что связано со внутренней работой системы, в частности алгоритм работы апдейтной программы.

Практически все что написано в этой книге, вы назвали чепухой. Ну что ж, вам виднее. SAP Press - фигня какая, а не издательство

Ну, вообще-то я написал, что именно я считаю неправильным в приведённой цитате. Сравнил с тем, что написано в книге: там всё правильно, а Вы, уважаемый коллега, переврали текст первого предложения. В книге так:

Почитал этот раздел — у автора в голове каша. Он не различает SAP LUW и DB LUW, а использует один термин: LUW.
Сначала пишет: "Each LUW starts and ends with an implicit or explicit commit rollback". Т.е. очевидно имеется в виду DB LUW.
А в том месте, которые цитировал vga, очевидно уже подразумевается SAP LUW.

LUW — это концепция обработки данных: либо всё, либо ничего. А DB LUW и SAP LUW — это два разных механизма технической реализации этой концепции.

Так что прямые апдейты работают в рамках DB LUW. Почему vga и dump относят их к SAP LUW, мне не понятно.


А где же тогда раскрывается??? Не обсуждаемую же книгу Вы имеете в виду. Где написано подробнее, чем в Library, про perfrom on commit, v1 и v2 процессы, порядок их выполнения, раскладка их по DB LUW'ам, принципы отката в случае ошибки, взаимодействие с блокировками, инструментарий (sm13) и т.д.? В SAP Library информация сжатая, но наиболее полная (по крайней мере по данном разделу). Не святотатствуйте — это наша Библия! Вот если найдёте источник, где объясняются все значения sy-oncom...

PS. Давайте не разводить флейм про издательства и переходить на взаимные оскорбления.



Я посмотрел книгу: Вы правы. Это ошибка. Во втором случае должно быть написано: "Triggering the update process to execute all three UPDATE TASK functions within one logical unit".

Если я вас чем то оскорбил, приношу извинения.

Если Вы не против, давайте все же вернемся к таблице в книге, раз уж появилась возможность видеть ее в оригинале.
Вы считаете, что строка в книге в таблице 'CALL FUNCTION IN UPDATE TASK' и галочка, что она выполняется в New LUW и примечение внизу - это ошибка?

Собственно, из-за нее и начался весь сыр-бор и разногласия в понимании происходящих процессов при апдейте.

Практикой, очень многое понимается под отладчиком. SAP Lib зачастую недостаточно для понимания работы системы, только часы проведенные под отладной дают ясность. Дебагер - вот наша библия

Там просто каша, в частности и из-за того, что автор не различает DB LUW и SAP LUW. Автор пишет, что submit начинает LUW и первый вызов call function in update task начинает LUW. Только чтобы он был прав, в первом случае нам нужно подразувать DB LUW, а во втором — SAP LUW. Но почему в таком случае в таблице не приведены ещё масса случаев, когда закрывается DB LUW?

PS. Может быть я не совсем прав, что SAP LUW начинается не с регистрацией первого update-модуля, а именно c submit. Можно считать, что set update task local не модифицирует уже открытй SAP LUW, а влияет на то, как он будет создаваться при вызове первого update-модуля.
В общем, это напоминает проблему, с какой стороны лучше разбивать яйцо.

Бесспорно. Ну разве что лучше было бы сказать не дебаггер, а исходный код. Хотя лучший инструмент для изучения системных программ, действительно дебаггер.

Можно и я отмечусь... (только не ногами! )
Попробую "показать пальцем"...

В общем:
Итак, когда выполнение доходит до CALL FUNCTION IN UPDATE TASK, то на самом деле вызова не происходит, а происходит INSERT в особую табличку VBЧТО-ТО-ТАМ. Записывается имя функции и значения всех параметров, которые указаны в этом вызове. Сколько вызовов, столько и записей в этой табличке и в той последовательности, в которой эти конструкции выполнялись.

Потом в какой-то момент случается COMMIT. Тогда во-первых, происходит обычный COMMIT в базе, и таким образом, "подтверждаются" записи в табличку VBЧТО-ТО-ТАМ, а кроме того "подтверждаются" и все остальные записи, которые в программе до этого COMMIT'а были сделаны операторами SQL INSERT/UPDATE/DELETE.
Во-вторых, передается сигнал особому параллельному процессу (процессу обновления), который все время работает на сервере приложений (таких процессов может быть несколько). Этот процесс начинает орабатывать записи из таблички VBЧТО-ТО-ТАМ, как раз в той последовательности, в которой выполнялись операторы CALL FUNCTION IN UPDATE TASK, и вот тут уже происходит настоящий вызов функций обновления с нужными параметрами и в нужной последовательности.

Что из этого следует: в процессе обновления данных получается как минимум два LUW, первый - в самой программе, которая выполняется в диалоговом или фоновом процессе, второй - в процессе обновления (update process). Именно поэтому случается, что пользователь нажал в FI документе Save, получил сообщение о том, что документ создан по номером ХХХХХХ, а потом, через некоторое время получил экпресс-сообщение об ошибке в процессе обновления.
Или, например, в программе вы вызываете BAPI, делаетте COMMIT и сразу делаете SELECT по номеру созданного документа, и может случиться так, что SELECT вернет sy-subrc = 4, из-за того, что Update process еще не успел обновить таблицы с документами.

Частности:
Режим локального обновления - SET UPDATE TASK LOCAL - если включен, то CALL FUNCITON IN UPDATE TASK выполняется как обычный вызов функции, а значит, после COMMIT'а все изменения буду гарантированно доступны для последующих SELECT'ов.

Приоритет (V1, V2...)
Приоритет обновления определяется атрибутами функции обновления. См. закладку Attributes в SE37
Start immed = V1
Immediate start = V2
start delayed = V3

Все функции обновления V1 вызываются процессом обновления в одном LUW. Если хоть в одном из них случилась ошибка, то откатывается все. После обработки обновлений V1 снимаются блокировки.
Все функции обновления V2 вызываются процессом обновления в одном LUW после того, как обработаны обновления V1. Если хоть в одном из них случилась ошибка, то откатывается все обновления V2.

Первый пример в исходном посте может привести к рассогласованности данных - UPDATE <customer table> сработает раньше, чем обновления основных таблиц, и если при обновлении основных таблиц случится ошибка, то в <customer table> записи "повиснут".