How to overcome "Failure getting record lock on a record from table"? - openquery

Question

I am running a query using OpenQuery and getting a peculiar error.
This is my query:
select * from OpenQuery("CAPITAOC",'SELECT per.*
FROM pub."re-tenancy" AS t
INNER JOIN pub."re-tncy-person" AS per
ON t."tncy-sys-ref" = per."tncy-sys-ref"
INNER JOIN pub."re-tncy-place" AS place
ON t."tncy-sys-ref" = place."tncy-sys-ref"
WHERE t."tncy-status" = ''CUR'' and place."place-ref"=''GALL01000009''')
This is the error message:
OLE DB provider "MSDASQL" for linked server "CAPITAOC" returned message "[DataDirect][ODBC Progress OpenEdge Wire Protocol driver][OPENEDGE]Failure getting record lock on a record from table PUB.RE-TNCY-PERSON.".
OLE DB provider "MSDASQL" for linked server "CAPITAOC" returned message "[DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Error in row.".
Msg 7330, Level 16, State 2, Line 1
Cannot fetch a row from OLE DB provider "MSDASQL" for linked server "CAPITAOC".
How do I read this data?

Answer 1

The record lock error:
In a multi-user environment it is useful to lock records that are being updated to prevent an other user session from accessing that record. This prevents a "dirty read" of your data.
To overcome this issue, I suggest looking at this article :
http://knowledgebase.progress.com/articles/Article/20255
The Transaction Isolation Level must be set prior to any other
transactions within the session.
And this is how you find out WHO has locked your record :
http://knowledgebase.progress.com/articles/Article/19833
Also, I would like to suggest that if you are using something like SQL explorer which does not Auto-commit your updates unless you ask it to, then the database table might be locked until you commit your changes.

Answer 2

I ran across this issue as well and the other answer's links were not as helpful as I had hoped. I used the following link: https://knowledgebase.progress.com/articles/Article/P12158
Option #1 - applies from OpenEdge 10.1A02 and later.
Use the WITH (NOLOCK) hint in the SELECT query. This ensures that no record locks are acquired. For example,
SELECT * FROM pub.customer WITH (NOLOCK);
The WITH (NOLOCK) hint is similar to using the Read Uncommitted isolation level in that it will result in a dirty read.
Option #2 - applies to all OpenEdge (10.x/11.x) versions using the Read Committed isolation level.
Use the WITH (READPAST) hint in the SELECT query. This option causes a transaction to skip rows locked by other transactions that would ordinarily appear in the result set, rather than block the transaction waiting for the other transactions to release their locks on these rows. For example,
SELECT * FROM pub.customer WITH (READPAST NOWAIT);
SELECT * FROM pub.customer WITH (READPAST WAIT 5);
Please be aware that this can lead to fewer records being returned than expected since locked records are skipped/omitted from the result set.
Option #3 - applies to all Progress/OpenEdge versions.
Change the Isolation Level to Read Uncommitted to ensure that, when a record is read, no record locks are acquired. Using the Read Uncommitted isolation level will result in a dirty read.
This can be done at ODBC DSN level or via the SET TRANSACTION ISOLATION LEVEL <isolation_level_name> statement. For example,
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Option 1 worked for me.