Здравствуйте, коллеги.

Помогите разобраться в вопросах сессии, коммитах и блокировках.

Вот если бы я законнектился к sql-серверу, сделал insert/update/delete, но не сказал commit, то, как я понимаю, изменения я в рамках коннекта к базе видеть буду, но в прочих коннектах изменения не видны, пока я не скажу commit.

Теперь в r/3. Я делаю batch-input, получаю через get parameter номер созданного документа и делаю по нему select из таблицы заголовка. Вот если я получаю данные заголовка (ну и subrc = 0 соответственно), то могу я быть уверенным, что commit закончился успешно и окончательно и блокировки тоже сняты? Или единственно надежным способом является использование логики программы RSENQRR2 (как вариант, ее же и от-submit-ить)? Мне надо после этого batch-input-а сразу же еще один сделать с этими же объектами (материалами в моем случае). Не хотелось бы на блокировки нарваться.

Спасибо.
Константин

блокировок не будет точно
а если получаешь subrc = 0 после селекта то прошел и COMMIT потому как CALL TRANSACTION запускается вроде как в другом LUW
ну если конечно всё происходит в синхронном режиме, а в случае асинхронного можешь не получить subrc = 0 потому как не прошел UPDATE еще

Делайте batch-input в режиме UPDATE 'L', тогда обновление (и сброс блокировок) будет происходить в той же задаче, и после выхода из транзакции у вас гарантированно данные будут уже в базе, а блокировки будут сняты.
Была какая-то нота, после применения которой с тем же успехом можно использовать UPDATE 'S', но номер не помню. Без этой ноты UPDATE 'S' иногда не успевает сбросить блокировки.
Через GET PARAMETER не оч. хорошо номер документа считывать, лучше собрать сообщения и там найти.

Стало быть, факт наличия записи - гарантия неотвала последующего batch-input-а по причине блокировки из-за предшественника. В моем случае именно это важно. Так и сделаю (и UPDATE-атрибут задействую обязательно).

Большое спасибо за помощь!
Константин.

Очень спорная техника. Особенно для использования в чужих больших транзакциях. Вот что пишет хелп:

This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.

Я бы выделил здесь два "скользких" момента:
1. This statement has no effect on low-priority update function modules.
2. ... and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed.

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

Ну все-таки надо учитывать, что основные таблицы будут обновлены с высоким приоритетом, т.е. в том же LUW. И блокировки будут сняты тогда же. Во всяком случае, бывали ситуации, когда нужно было создать цепочку документов и без режима 'L' не получалось.
В чужих больших транзакциях? Вы имеет в виду вызывать CALL TRANSACTION в юзер-экзитах? Согласен, что не стоит этого делать.

Конечно, с большой долей вероятности этот способ сработает, однако надо учитывать и то, что есть вероятность, что он либо не сработает, либо - что ещё хуже - сработает некорректно.

А вот эта ветка вас не устроит?
http://sapboard.ru/forum/viewtopic.php?t=15449

Блокировки интересовали для ракурсов материала и клиента, а они в V1-секции, насколько я понимаю.
Практически ситуация такая: надо по одной кнопке последовательно сделать отпуск материала, потом его же двинуть по складам, и затем на клиента нарисовать счет. Технически будет последовательность: batch-input для поставки, bapi для перемещения и batch-input для счета. Наверное для этих целей следовало бы использовать воркфлоу (я неправ?), но по ряду причин было принято решение сделать экран выбора заказов-позиций и по кнопке запустить процесс из трех транзакций.

Спасибо, попробую.

Хорошая мысль, кстати. Там и встроенный механизм ожидания разблокировки есть. Так что рекомендую Workflow (на будущее, по крайней мере).