Re: SQL FETCH

I pasted a piece from the Info Center.  Apparently you
can't ensure that the cursor is "sensitive" to db
updates.  SCROLL "may or may not have immediate
sensitivity" and DYNAMIC SCROLL is ignored when "The
ORDER BY or GROUP BY clauses specify columns which are
not all from the same table" which is the case in my
scenario.

Is this everyone else's experience or am I missing
something?

Thanks, 
Phil

from
http://publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/info/index.htm
:

SCROLL 
Specifies that the cursor is scrollable. The cursor
may or may not have immediate sensitivity to inserts,
updates, and deletes done by other activation groups.
If DYNAMIC is not specified, the cursor is read-only.
In addition, the SELECT statement cannot contain a FOR
UPDATE clause. 

DYNAMIC SCROLL 
Specifies that the cursor is updateable if the result
table is updateable, and that the cursor will usually
have immediate sensitivity to inserts, updates, and
deletes done by other application processes. However,
in the following cases, the keyword DYNAMIC is ignored
and the cursor will not have immediate sensitivity to
the inserts, updates, and deletes: 
Queries that are implemented as temporary result
tables. A temporary result table is created when: 

The ORDER BY or GROUP BY clauses specify columns which
are not all from the same table


--- David Wright <dwright2@tampabay.rr.com> wrote:
> Is it possible that the SQL statement in error just
> recently started getting
> records?
> What OS version are you at?  (There was an RPGSQL
> Bug about a year ago)
> Are you sure it is really broken?   :)
> 
> 
> ----- Original Message -----
> From: "Peter Dow" <pcdow@MailAndNews.com>
> To: <RPG400-L@midrange.com>
> Sent: Friday, November 17, 2000 12:05 AM
> Subject: Re: SQL FETCH
> 
> 
> > Hi Mark, Dave, Phil,
> >
> > Assuming that Mark and Dave's solution solves the
> problem, why did it work
> > for months before failing? Did they just fail to
> notice it? Did a PTF or
> > release upgrade change the behavior? Just a
> recompile forgetting to
> specify
> > *NONE? I'm always suspicous when a program that
> hasn't been touched for
> > months suddenly starts to behave differently. To
> paraphrase Albert E, "IBM
> > doesn't play dice with OS/400's behavior!" Or do
> they?
> >
> > Curious,
> > Peter Dow
> > Dow Software Services, Inc.
> > 909 425-0194 voice
> > 909 425-0196 fax
> >
> >
> > ----- Original Message -----
> > From: "M. Lazarus" <mlazarus@ttec.com>
> > To: <RPG400-L@midrange.com>
> > Sent: Thursday, November 16, 2000 7:44 PM
> > Subject: Re: SQL FETCH
> >
> >
> > > Phil, Dave,
> > >
> > >   You can specify WITH NC to explicitly turn off
> commitment control.
> Then
> > > you don't have to worry about remembering it on
> the compile.
> > >
> > >   -mark
> > >
> > > At 11/16/00 07:23 PM -0500, you wrote:
> > > >Recompile the program with Commitment Control
> *NONE.
> > > >
> > > >That should do it,
> > > >Dave
> > > >
> > > >----- Original Message -----
> > > >From: "Phil Groschwitz"
> <sublime78ska@yahoo.com>
> > > >To: <RPG400-L@midrange.com>
> > > >Sent: Thursday, November 16, 2000 2:47 PM
> > > >Subject: SQL FETCH
> > > >
> > > >
> > > > > I have a display file pgm using embedded
> sql.  Has
> > > > > been in place for months with no problems. 
> Now,
> > > > > however, when a record is updated (like by
> another
> > > > > user) and the first user updates the screen,
> which
> > > > > does a FETCH FIRST, then clears the subfile,
> then
> > > > > loads the subfile using FETCH NEXT, the
> changed record
> > > > > reflects the original value.  Any added
> records are
> > > > > not retrieved.  Only when the cursor is
> closed and
> > > > > reopened does the correct data display.
> > > > >
> > > > > Any ideas?
> > > > >
> > > > > Thanks, Phil
> > >
> > > +---
> > > | This is the RPG/400 Mailing List!
> > > | To submit a new message, send your mail to
> RPG400-L@midrange.com.
> > > | To subscribe to this list send email to
> RPG400-L-SUB@midrange.com.
> > > | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
> > > | Questions should be directed to the list
> owner/operator:
> > david@midrange.com
> > > +---
> >
> > +---
> > | This is the RPG/400 Mailing List!
> > | To submit a new message, send your mail to
> RPG400-L@midrange.com.
> > | To subscribe to this list send email to
> RPG400-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
> > | Questions should be directed to the list
> owner/operator:
> david@midrange.com
> > +---
> >
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to
> RPG400-L@midrange.com.
> | To subscribe to this list send email to
> RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list
> owner/operator: david@midrange.com
> +---


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---