PRACTICAL GUIDEUnder review

Record locking, writing and concurrency

Checks locks before assigning fields and distinguishes unlocking from transactions.

Record locking, writing and concurrencyAdvPL

01 · OVERVIEW

Overview

RecLock(cAlias,.F.) attempts to lock the current record for editing; .T. begins insertion. Assign fields only after a true result. The alias cannot be a query or read-only. MsUnlock finishes the record operation on the current alias; inside an explicit transaction the physical lock may remain until the end, although MsUnlock is still required. Unlocking does not confirm an entire business operation. The fragment requires custom ZZ1, field Z1_DESC and a previously located test record. It is not direct standard-table maintenance. (TOTVS, n.d., refs. 1–2)

Return value

No single return value: this is a composite workflow.

03 · PRACTICAL EXAMPLE

Commented example

// Fragment: writable ZZ1 open, with Z1_DESC and a positioned test record.
If !ZZ1->(Eof())
    If RecLock("ZZ1", .F.)
        // Fictional rule and value, for a custom test table only.
        ZZ1->Z1_DESC := "EDITORIAL TEST"
        ZZ1->(MsUnlock())
    Else
        ConOut("Record unavailable; no assignment.")
    EndIf
EndIf

Expected result

On a successful lock, proposes updating Z1_DESC in the fictional table; on failure, makes no assignment. The fragment does not implement complete error recovery. Under review: editorial example neither compiled nor run in Protheus. Check includes, release, RDD and context before testing.

BEST PRACTICES

Reread and validate criteria under the lock, keep the section short and handle errors to finish the operation. Avoid dialogs and infinite retries; test with two sessions and any outer transaction.
Under review: editorial example neither compiled nor run in Protheus. Check includes, release, RDD and context before testing.

Record locking, writing and concurrency

Overview

Return value

Commented example

Related content

Comments