This is not the case. I use the two read technique when updating
records, the "on update change timestamp" is a great tool.

Checking the programs I found one that had a "select" (under commitment)
and it may have returned without releasing the record. I added "with
NC" to the select, and since then I had no more records locked, but
because the problem appeared very seldom, I am not sure if that was the

Is it possible that the "select" was locking the records? I have
"commit" or "rollback" on every update, but the "select" was alone.

Thanks for all your comments,
On 09/12/2015 03:37 PM, Booth Martin wrote:
It sounds like you have programs that allow user intervention between
the read (with lock) and the update?

Please consider programs that have two reads: one read (no lock) to get
the needed data, then do the user stuff, and compare the new user data
to the original data. If different, do an update routine where you read
the record (with lock), check if the original data is the same as the
just retrieved data (in case of changes from another workstation), and
if still ok, update the record.

On 9/12/2015 11:41 AM, Raul A Jager W wrote:
Sometimes a record gets locked, DSPRCDLCK shows the job that is holding
the record, but not the program that caused the lock.

It is likely that a program returned (or failed) without releasing all
records it has read for update, but I don't know which one.
DSPJOB just shows in the stack the http server ready to receive data and
the log shows only errors or info messages.

How can I find out which program left the record locked?


-- Este e-mail fue enviado desde el Mail Server del diario ABC Color --
-- Verificado por Anti-Virus Corporativo Symantec --

-- Este e-mail fue enviado desde el Mail Server del diario ABC Color --
-- Verificado por Anti-Virus Corporativo Symantec --

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.