Re: SQL select seems to be creating a lock on a file

With only what has been given, that the two programs have an apparent conflict, is clearly problematic. Nothing supports Working As Designed for the overall scenario; as described.

That a lock might remain for a pseudo-closed cursor could by itself be WAD, however, the described conflict seems very improbably to be WAD; i.e. the lock on the file, member, and data for the given query should not conflict with the for-Update F-spec when the file is opened in the RPG program. The feedback offered in\by prior replies would only be a waste of time, if the apparently failing scenario were deemed summarily to be WAD, and therefore ended up being ignored solely because something [e.g. alternate timing] is eventually found to circumvent the issue that arose. A circumvention seems likely to be merely avoidance, not resolution.

There is clearly something working contrary to expectations, given what information we have been given. The additional information I had requested would hopefully clarify what is the conflict; even if not additionally reveal why the conflict arose contrary to expectations.

Regards, Chuck

On 23 Jul 2013 11:28, Alan Shore wrote:

My investigation is also showing "working as designed". <<SNIP>>
Basically - it's a timing issue. <<SNIP>>
My apologies to everyone for wasting their time. <<SNIP>>

Charles Wilt on Tuesday, July 23, 2013 2:14 PM wrote:

It's not surprising that the SQLRPGLE program keeps a lock on the
file, that's working as designed in order to minimize the time it
takes to access it again.

However, it should not interfere with RPG program opening the file
for update or actually updating it.

Something else is going on <<SNIP>>