Обновите буфер и верните режим блокировки к исходному

Эта ветка может быть полезной в качестве фона - она ​​рассказывает о том, как определить текущий статус блокировки.

http://stackoverflow.com/questions/26136842/progress-4gl-display-buffer-lock-type?rq=1

В конечном итоге я думаю, что это то, что вам действительно нужно:

    /* lightly tested psuedo code...
     */

    procedure updateMyField:

      define input parameter myRowid  as rowid.

      define buffer updMyTable for myTable.  /* this limits the scope of the buffer to this procedure */

      do for updMyTable transaction:  /* FOR "strong scopes" the buffer to this block */
        find updMyTable exclusive-lock where rowid( updMyTable ) = myRowid no-error.  /* the EXCLUSIVE-LOCK is scoped the FOR block -- when we leave the block it is released */
        if available updMyTable then
          assign
            updMyTable.myField = "new value"
          .
         else
          do:
            message "could not get an exclusive-lock on myTable".
            /* or whatever error handling you need... */
          end.
      end.  /* the transaction is committed and the lock is released -- no need to change its status */

      return.

    end.

    /* main block
     */

    find first myTable no-lock.
    display myTable.myField.
    pause.

    run updateMyField ( rowid( myTable )).

    find first myTable no-lock.
    display myTable.myField.
    pause.

Странно, что тип блокировки не является атрибутом дескриптора буфера. Казалось бы, очевидная необходимость.

Вы можете найти записи _lock для recid, но вам также нужно найти идентификатор таблицы, что означает поиск его в _file из дескриптора: table.

Итак, если у вас подключена только одна база данных, у вас будет что-то вроде:

FIND _file NO-LOCK WHERE _file-name = bufHandle:TABLE.
FIND _lock NO-LOCK WHERE _lock-name = USERID()
    AND _lock-table = _file-number
    AND _lock-recid = bufHandle:RECID.

Если запись существует, вы знаете, что у вас есть блокировка. _Lock_flags сообщит вам, какие у вас блокировки. Я думаю, что S - это общий доступ, а E - эксклюзивный, и думаю, что если есть Q, то вы ждете этой блокировки, чего я бы не ожидал, если у вас уже есть блокировка для записи.

Затем вы можете повторно заблокировать запись в соответствующем состоянии, если она еще не была заблокирована исключительно при запуске вашей функции.

Вы не можете разблокировать такую ​​запись, когда находитесь в транзакции. Если вы попытаетесь, монопольная блокировка превратится в блокировку неопределенности до тех пор, пока транзакция не завершится и изменения не будут зафиксированы в базе данных. Это сделано для предотвращения проблем с целостностью данных. Если вы смотрите на поле _Lock-Flags, блокировка лимба будет буквой «L». Вы также можете использовать Promon для проверки статуса таблицы блокировок.

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

MESSAGE TRANSACTION VIEW-AS ALERT-BOX.

Вот документация OpenEdge по блокировке записей и области транзакций: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/gsabl/handling-data-and-locking-records.html#

Я думаю, что лучше всего использовать ваше второе решение. Определите локальный буфер (нет необходимости называть его временным буфером, который не является четко определенным термином в OpenEdge IMO), загрузите запись параметра в этот буфер, используя rowid (в основном бесплатная операция, если буфер параметров уже был заблокирован) и измените свой локальный буфер. Не беспокойтесь о том, что что-то устареет. Цитата http://knowledgebase.progress.com/articles/Article/P4548 (пожалуйста прочтите статью полностью)

В пуле записей клиента одновременно может существовать только одна копия записи. Это означает, что в следующем случае показаны два буфера, указывающие на одну и ту же физическую копию клиента 1. Это означает, что после выполнения следующего кода

DEFINE BUFFER cust FOR customer.
DEFINE BUFFER cust1 FOR customer.
FIND FIRST cust no-lock.
FIND cust1 where rowid(cust1) = rowid(cust) exclusive-lock.
cust1.name = 'xyz':U.

cust.name также будет иметь значение xyz. Я просто попробовал код, чтобы убедиться. На самом деле я также подтвердил, что блокировка не в буфере, а в записи. Я также мог бы назначить cust.name, даже если в find для cust не используется блокировка. Если за пределами вашей программы / процедуры транзакции еще нет, то при выходе из процедуры блокировка будет снята. Определенно не пытайтесь работать с _lock, если это не необходимо, чтобы показать пользователю, который блокирует запись, которую он хочет изменить (или в аналогичных целях).

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

Итак, хороший способ обновить переданный буфер - получить ту же запись от ROWID и отдельно обновить ее в другом буфере:

DEF BUFFER myFirstBuffer FOR MyTable.
DEF BUFFER mySecondBuffer FOR MyTable.

FIND FIRST myFirstBuffer WHERE myFirstBuffer.MyField = "myvalue" NO-LOCK.

/* At this moment myFirstBuffer.MyField is "myvalue" */

FIND FIRST mySecondBuffer WHERE ROWID(mySecondBuffer) = ROWID(myFirstBuffer) EXCLUSIVE-LOCK.
ASSIGN mySecondBuffer.MyField = "mynewvalue".

/* Now both 'myFirstBuffer.MyField' and 'mySecondBuffer.MyField' match ("mynewvalue")! */

Progress, кажется, обрабатывает все изменения данных и соответственно обновляет буферы. Однако я считаю, что это не сработает, если запущены 2 отдельные программы, f.ex myprogram1.p и myprogram2.p, и они обе обновляют одну и ту же запись в разное время (хотя это уже другая история ...). Раньше у нас были проблемы с TRIGGERs, когда затронутые триггером поля не обновлялись в буфере.

Но вкратце, я считаю, что лучше всего запросить запись отдельно с помощью ROWID и обновить ее таким образом. Я действительно считаю, что разработчик не должен использовать FIND CURRENT myBuffer NO-LOCK., поскольку это изменит locking-mode записи и может нарушить логику использования myBuffer позже.