Всем привет Уважаемые!

Подскажите мне по следующему вопросу:
Есть Z* таблица (ztbl). Эта таблица в самописной проге засасывается во внутренную таблицу itab и вывадится в ALVGrid на редактирование.
Одновременно эту таблицу могут корректировать несколько пользователей. Думаю, что последовательностьдействий должна быть такая:
1)Отлавливаем событие Data_Changre ALVGrid
2)В событии пытаемся заблокировать редактируемую запись. Если удачно хорошо, иначе вываливаемся обратно в редактирование строки с сообщениемю
3)Делаем UPDATE таблицы по ключевым полям с установкой новых отредактированных значений
4)Делаем commit
5)Разблокируем запись
6)Обновим ALVGrid

Вот не совсем понимаю, как нужно делать п.2, 4 и 5. Подскажите как это можно проделать?

В SE11 создаем объект блокировки 'EZOBJ'.

2) Блокируем через ф.м. ENQUEUE_EZOBJ

5) Разблокируем объект через ф.м. DEQUEUE_EZOBJ

2 и 5 шаг с помощью объектов блокирования, смотрите в se11. Там даже хелп есть... Обновление через тот самый UPDATE, а коммит COMMIT WORK [AND WAIT].

Я думаю, что надо сделать так:
Другой вариант - создать объект блокировки. Описание смотри в хелпе, раздел SAP Locking

А какой смысл в этом? На мой взгляд при редактировании все выбранные записи должны блокироваться в момент их выборки.
Иначе при таком алгоритме после блокирования записи необходимо перечитывать запись из базы, сравнивать не былали она изменена, и если её не успели поменять то только тогда возможен переход к следующим шагам.

Поэтому и мгновнное сохранение редактируемых записей в БД - так-же далеко не идеальный результат, тем более в той реализации, которая предрагается - ведь в этом варианте у пользователя не остаётся никаких шансов отказаться от "не правильных" изменений.

to sy-uname:
Тут мысль такая: когда ячейку кол-ва исменили и нажали Enter, то переходим в Data_change и там мне нужно используя ключевые поля редактируемой записи поставить блокировку на эту запись в Z-таблице (если ее еще не удалили). После этого делаем ее UPDATE на свое значение и снимаем блокировку. Естественно, если кто-то паралелльно пытался корректировать эту-же строку, то значение кол-ва в этой строке поменяется очередно -сначала для одного, затем для другого. Так, чтоздесь я думаю все нормально.

to Timon&Pumba:

Создал объект блокировки EZRESURS, со стандартной блокировкой от записи. Стал искатьФМ с именем ENQUEUE_EZRESURS и не нахожу. в чем дело? (Прошу прощения если вопрос ламерский, с блокировкаминикогда не работал).
А Commit Work нужно ставить до снятия блокировки. Или снятие блокировки само инициирует Commit?

При таком подходе не имеет смысла заморачиваться с саповскими блокировками - достаточно просто тупо апдейтить таблицу - кто последним нажмёт ENTER, тот и будет прав.

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

Вопрос: Почему после создания объекта блокировки и его активации у меня не появились функциональные модули ENQUEUE_ / DEQUEUE_ ?

А что его искать? В объекте блокирования в меню "перейти к -> модули блокировки"

На самом деле ничего не блокируется. Модуль блокирования всего лишь создает запись в специальной табличке о том что объект блокирован. Если сам не проверишь блокировку объекта никто не мешает сделать с ним все что угодно. Commit конечно нужно ставить до снятия блокировки.

Так. Сами фанкциональные модули нашел (спасибо sy-uname)

Теперь не совсем понятно, что на самом деле происходит при их использовании.
Насколько я понял, эти модули просто пишут строчку о блокировке записи в спец.таблицу, подразумевая, что все остальные программы при обращении к пользовательской таблице тоже будут использовать эти функциональные модули для блокировки. И если все остальные программы действительно пользуются этими ФМ, то можно сказать, что блокировки работают. А если отдельные программы например сразу запускают UPDATE строчки, которая ранее уже с помощью ФМ была "заблокирована", то эта отдельная программа "заблокированную" строчку поменяет, несмотря на то, что ее ранее уже "заблокировали"? Или все-таки SAP сам неявно запускает для этой программули блокировочные ФМ?

Именно так. SAP отдал задачу блокировки на волю ABAP-еров.

Да, полная каша...
А прикольно будет, если пользователь А сделает изменения в десяти разных строках и пользователь Б тоже полчаса будет что-нибудь долбить в грид, а потом оба нажмут SAVE!
При таком подходе уж лучше предложить следующий вариант:
- в свойствах грида усланавливаешь выделение единственной строки
- в TOOLBAR вешаешь кнопарь EDIT
- при нажатии кнопки вешаешь блокировку по ключу данной строки, перечитываешь ее из базы и рефрешишь грид
- только после этого даешь править данные в строке
- после сохранения запрещаешь редактирование и снимаешь блокировку

Всё зависит от того, как пользователи работают с данными: конкурентно или нет.

Если конкурентно, т.е. например в сценарии бронирования билетов, то спору нет, блокировки нужны. При этом есть свобода выбора: ставить ли Shared-блокировку при просмотре документа или нет. При продаже ж/д билетов блокировка не ставится, т.к. не раз бывало, что кассирша сообщает: "Ой, у Вас билет из под носа увели". И это правильно, т.к. на просмотр открывается очень много позиций и при наличии S-блокировки практически невозможно было бы купить билет поставив X-блокировку. А вот если бухгалтер открывает один-единственный документ на просмотр, то S-блокировка допустима, т.к. в достаточной степени маловероятна одновременная попытка открыть документ на редактирование, и даже при осуществлении таковой проблема решается телефонным звонком: "Юля, закрой, пожалуйста, такой-то документ".

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

В этом случае я когда-то реализовывал следующий алгоритм: после нажания на кнопку Save таблица блокируется, читается текущая информация, затем сравниваются три копии данных (a — первоначально считанную, b — исправленную пользователем, и c —текущую). Если (b ne a) and (a ne c), то пользователю предлагается выбрать: записать в базу b или оставить c.

Спасибо Sibrin, интересно было почитать.