Re: SQL scroll cursor slow performance

>
> 1. Do you think this would require more or less complexity to write
> using native I/O statements?
           1- I thin that native I/O require less complexity when selection
(or sum ...) criteria are complex.


> 2. What reasons would you give for choosing SQL or native (remember, for
> performance purposes all the indexes have to exist, so that's not an
> reason to choose SQL)?
            2- I choose SQL when i make a simple select with variables
filters, it is like openqryfile but very, very more simple to read for
others.
                Another advantage for me, i can use the same template
(especially for sub-file) with SQL or native IO.


> 3. Do you think it would perform better in native or SQL?
            3- It depend ! In my experience i saw some faster other slower
... because of the request itself (bad writting) or because of the number of
rows in tables...

>
> 4. Which do you think would take longer to debug?
            4- IO, SQL give me a readable statement and i can easy cut and
past to test it in interactive sql session.

> 5. Which would be easier to maintain?
            5- SQL but it is just my opinion and i don't use complex
statements, i prefer cut a complex one into many simple agains performance
perhaps. but one more time it depend about the task i must perform.


> (A side issue is to ask why you are running through the exact same
> cursor four times; where are the report lines going?  One of the first
> things I'd be looking at is how to run through the data once, but that's
> just my old dinosaur thinking.)

        Darren depending on the number of rows, it will be perhaps good to
store data into a temporarty table or a userspace or table or ???? imagine
that you have to provide 4 more reports ?


>
> Joe
>
> > From: darren@xxxxxxxxx
> >
> > I'm using an SQL scroll cursor with the code shown below.  I call the
> > $ResetCurs1 subroutine and read through the entire cursor 4 times
> because
> > I generate the report 4 times with 4 different headings.
>
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>