Classics Forum

RE: SCROLL CURSOR with temp table

Posted By:
Date:

What I have done in this case is the following:

Only fetch rowids or keys in the SCROLL CURSOR and fetch the actual data only
when you are filling the screen array for the <N> rows that will be displayed

Art S. Kagel

----- Original Message -----
From: Ganesh R <Ganesh.R@fmr.com>
At: 3/ 9 23:54

> Hi,
>
> FETCH ABSOLUTE is something new for me and I would like to know more
> about it. Can you explain the same or give me pointers where I can get the
> explanation.
>
> For a long time I had a question in mind that I was not able to
> solve. Say, I have a scroll cursor displaying records in a user screen for
> updating records (using 4GL). Let's assume I have 30 records fetched. The
> user scrolls to the 20th(using fetch next) and he updates the record. He
> scrolls further to 28th record. Now if he does a scroll back (using fetch
> prev), by the time he reaches the 20th record he will not see the update he
> had done(obviously because the cursor holds only a snap shot of earlier
> status).
> I want to make updated record available to the user when he scrolls back
> without exiting the form.
>
> Can I achieve this somehow?
>
>
>
> Thanks & regards,
> Ganesh
>
> "Any comments or statements made in this email are not necessarily those of
> FISC India Pvt. Ltd. or any of the Fidelity Investments group companies. The
> information transmitted is intended only for the person or entity to which
> it is addressed and may contain confidential and/or privileged material. If
> you have received this in error, please contact the sender and delete the
> material from any computer. All e-mails sent from or to FISC India Pvt.
> Ltd. may be subject to our monitoring procedures"
>
> -----Original Message-----
> From: Art S. Kagel [mailto:kagel@bloomberg.net]
> Sent: Friday, March 07, 2003 11:53 PM
> To: informix-list@iiug.org
> Subject: Re: SCROLL CURSOR with temp table
>
> On Thu, 06 Mar 2003 22:50:26 -0500, Jonathan Leffler wrote:
>
> > Art S. Kagel wrote:
> >> The subject may be a red herring but here it is. I have a query that
> >> when run in dbaccess, so using a normal cursor, returns 177 unique
> >> rows. In my 4GL app the query is opened with a SCROLL CURSOR and the
> >> rows fetched in a loop similar to this:
> >>
> >> FOR elem=1 TO 177
> >> FETCH ABSOLUTE elem INTO primary[elem].fields.*
> >> END FOR
> >>
> >> When the rows are displayed (or I look at the array primary in the
> >> system debugger, compiled with C4GL) I see four copies of the first row
> >> followed by 4 copies of the second row etc. In effect the first
> >> element of the SCROLL CURSOR is being returned for ABSOLUTE items 1-4
> >> the second for items 5-8, etc.
> >
> >
> > O Art! You know better than not to quote version numbers.
>
> <Hanging his head in shame, Art responds:>
> You're right, I'm sorry. C4gl R7.20UD6 on DGUX and R7.30UC6 on Solaris
> these are not the latest but they've been rather stable for us to date
> and they represent two very different releases on two different
> platforms.
>
>
> > It sounds very weird and dubious, but if you're using a UC1 version of
> > I4GL other than 7.32.UC1 (which I'm using and which seems to be pretty
> > stable), then that may be a version-specific bug.
> >
> Mmm <nodding agreement>.
>
> > Did you try running the 'scroll cursor' into the array without having it
> > declared as a scroll cursor? In fact, why do you need to use a scroll
> > cursor at all if you select into an array?
>
> No. Why? This is an interactive app that displays a pageful of records.
> The array holds 100 the screen form array 16. As long as the user pages
> around within the 100 that are in memory OK but if the user goes to page 7
> or later then I slide the last 50 up to the top of the array and fetch
> the next 50 from the scroll cursor and display the selected 16 from the
> middle of the array. Likewise if the user pages back to a point
> before the second 50 I need the scroll cursor to refill the first 50
> after sliding the second 50 down to the end of the array. So what I have
> is a 16 row window in the display form that is view into the 100 row 4GL
> array which is in turn a window into the query results which are
> arbitrarily large. This double sliding window 'technology' is the basis
> for the 'infinite' display array simulation code in my few 4GL
> applications.
>
> Forgot to mention, when I walk the code in the debugger the function that
> fetches each row into the array is passed the 'absolute' row number and
> the array index into which to load it. These values both increment with
> each call correctly. I see the row number being pushed onto the 4gl
> stack and popped into the describe structure for the FETCH ABSOLUTE call.
> It askes for row #2 for example. Before the fetch array element #2 is
> garbage, after the fetch function is called it contains the exact same
> data as element #1. The same for element #'s 3 & 4 then element #5
> returns the row that dbaccess is returning as row #2!
>
> It gets weirder. I hereby affirm that if I run the EXACT query in
> dbaccess I got 177 unique records yesterday (179 today as new data was
> loaded this AM (and a similar COUNT(*) returns a value of 177 [or 179]),
> however, the scroll cursorin the 4GL code returns quadruplicated rows!
>
> Now, and here's the truly weird part, just on a lark and because I got
> bored waiting for the post to get around and arouse responses, I added a
> UNIQUE clause to the query and VOILA! it's working fine again as it was
> before I added the joins to the temp table to display code expansions
> based on a disk file (loaded into the temp table by an ESQL/C function).
> Oh, and yes I added code the verify that the records in the temp table
> are unique just in case I'm loading them differently when I test in
> dbaccess. There are exactly one of each.
>
> Very odd.
>
> Art S. Kagel

Messages In This Thread

• RE: SCROLL CURSOR with temp table
  ART KAGEL, BLOOMBERG/ 65E 55TH -- Tuesday, 15 April 2003, at 3:55 p.m.
  • RE: SCROLL CURSOR with temp table
    Kipp Sherry -- Tuesday, 15 April 2003, at 3:55 p.m.

Classics Forum is maintained by Administrator with WebBBS 5.12.