|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com 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.