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

[CRPence <CRPbottle@xxxxxxxxx>]

  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>>