Какая разница? Это не имеет значения.

Имеет.
Хотя бы для того, чтобы определить объект блокирования, который нужно будет проверить при ожидании выполнения 1 транзакции

А общего алгоритма разве нет?
Я могу и сама найти.

можешь.
Сначала прочитай концепцию блокировок, затем запусти свою транзакцию в режиме редактирования, в параллельном режиме запусти транзакцию SM12.
Найдешь имя объекта блокт\ирования - и вперед

Нашла имя объекта. Нашла ФМ ENQUEUE_READ, который возвращает список блокированных объектов. Но вот в этом списке может быть несколько записей. Можно использовать seqg3-gusrvb для более точного позиционирования, но надо знать его значение. Как его определить именно для данной транзакции и для данного режима?

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

ENQUEUE_READ не поможет.
1.Нужно вызвать в цикле ФМ ENQUEUE_<имя объекта> для попытки блокировки.
Если блокировка не снята, то ФМ выдаст sy-subrc <> 0. Ждем какое-то время, например 1 секунду. Продолжаем выполнять цикл.
2.Если блокировка к моменту вызова ENQUEUE_<имя объекта> была снята, то sy-subrc = 0, документ заблокирован.
Снимаем блокировку с помощью ФМ DEQUEUE_<имя объекта>, выходим из цикла.
3.запускаем 2 транзакцию.

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

ЗЫ: Если бы я знал транзакцию, то написал бы более точный код с аргументами блокирования

ЗЫ: Если бы я знал транзакцию, то написал бы более точный код с аргументами блокирования [/quote]

Ещё чего, сама сделаю. Точнее, уже сделала. Спасибо за консультацию. Но всё равно остаётся вероятность непрохождения транзакции, особенно если убрать вероятность зацикливания. То есть "быть или не быть" в смысле циклить или ждать ошибку. Смешной SAP, ей богу.

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

Ну уж далеко не DBF-формат или вы знаете способ одновренного изменения данных в многопользовательской среде без концепции блокирования/защиты от изменений объектов?

А на что вы обиделись? Я не говорю про концепцию блокировок, у меня конкретный случай:

Я у себя запустила две одинаковые транзакции. Если при этом проверять аргумент блокировки, то sy-sybrc <> 0, но в этих транзакциях в одной запись вставляется, а в другой висит на редактировании. Они могут работать параллельно, и не мешают друг другу. Получается, я не могу задать входной параметр в ENQUEUE_EX, так как не знаю его, а блокировка существует , тем не менее.

Если бы знать, как формируется запись seqg3 в списке блокировок (если посмотреть ФМ ENQUEUE_READ), то можно было бы коктретно указать на нужную мне транзакцию по аргументу блокировки, но я не знаю, как это сделать.

Значит идем по пунктам:
1. Нсли в первой транзакции что-то вставляется, то во второй явно редактируется в этот момент другое.
2. Если это первое еще не вставилось то и аргументов блокирования на это нечно еще нет, а вот на то второе аргумент блокирования есть. Вы я смотрю как партизан в гестапо, храните тайну что за транзакции пускаете последовательно, ну да ладно. Так вот обычно объект блокировки имеет аргументы. К примеру если это заказ ММ, то аргумент блокирования это номер заказа, для материала это код материала...
3. Я так и не понял в чем проблема, в том как это реализовывать? Ну или найдите рядом того кто это знает или читайте справку и смотрите исходные тексты системы. Благо второе и третье в свободном доступе.

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

Попробуй посмотреть таблицу VBHDR (пример в ФМ C14Z_COMMIT_CHECK)

Спасибо, abap! Похоже, это то, что нужно! Взяла SELECT из C14Z_COMMIT_CHECK, подставила имя транзакции. В работе вроде видно, что запись появляется в таблице, а потом удаляется. Будем надеятся, что работать будет.


Спасибо всем. Поставила двойной заслон в проге. Надеюсь, что больше сообщений типа "Запись не создана" не будет.

Попытаюсь объяснить.
1. Создается некая запись (уж буду партизаном извиняйте) в 1 транзакции. Тут же в моей проге запускается 2 транзакция на редактирование этой вновь созданной записи.
2. Вот тут и возникает иногда ошибка типа "Запись такая-то не создана", хотя она есть!
3. При создании новой записи никаких блокировок по объектам нет - я проверяла. То есть в SM12 пусто. Видимо, INSERT не делает блокировку, только UPDATE.
4.Abap дал мне хороший совет - в этом ФМ проверяется не блокировка, а работа самой транзакции. Когда работа транзакции 1 завершена - можно запускать вторую.