× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



At the first look i will say : houla native I/O sure, at the second i will
say : bah it seems pretty clear that SQL may be definitivly the answer.

What will make my choice will be (if i need) the performance.
The other will be who is going (able) to maintain SQL ? not any programmers
here know SQL (or just some select * from where ....)

I must answer also, that i have never used such statements...

----- Original Message ----- 
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, June 23, 2005 7:09 PM
Subject: RE: SQL scroll cursor slow performance


> > From: Richard ECUYER
> >
> > >
> > > 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.
>
>
> Thanks for your input, Richard!  However, I was really hoping for
> answers specific to this single statement, rather than a broad
> comparison of SQL vs. native.  I should have included the SQL in my
> previous post!
>
> For example, the statement does not have variable filters but it does
> have complex selection and grouping criteria (I'm including it below).
> Based on that, would you think this specific statement was easier to
> write in native I/O or SQL?  Can you answer the same questions looking
> only at the single statement in question?
>
> Poll questions (anybody who feels like it, please answer):
>
> 1. Do you think this would require more or less complexity to write
> using native I/O statements?
>
> 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)?
>
> 3. Do you think it would perform better in native or SQL?
>
> 4. Which do you think would take longer to debug?
>
> 5. Which would be easier to maintain?
>
> Joe
>
>
> >      C+ declare C1 scroll cursor for
> >      C+ select PLPRD, sum(PLQTY) as PLQTY,
> >      C+        PLCTN, sum(PLWGT) as PLWGT,
> >      C+        'BULTOS' as PTyp1, 'BUNDLES' as PTyp2,
> >      C+        sum(PHCWT)+sum(PLWGT) as GWgt,
> >      C+        ifnull(min(FKENGD),' ') as EDSC,
> >      C+        ifnull(min(FKSPND),' ') as SDSC,
> >      C+        ifnull(min(F5COO),' ') as F5COO,
> >      C+        ifnull(min(F2TOUM),' ') as F2TOUM,
> >      C+        ifnull(min(HARPMT),' ') as HARPMT,
> >      C+        ifnull(min(F5SCST),0), ifnull(min(F2FACT),1),
> >      C*        multiply by duty rate percentage
> >      C+          ifnull(case
> >      C+            when :FEDATE>=min(F4COOD)
> >      C+              then 0
> >      C+            when :FEDATE<min(F4COOD)
> >      C+              and min(FLPROF)='Y'
> >      C+              then min(FLPROR)
> >      C+            when :FEDATE<min(F4COOD)
> >      C+              and min(FLPROF)<>'Y'
> >      C+              then min(FLNORR)
> >      C+            end,0)
> >      C+
> >      C+   from PCHL01 join PCLL01
> >      C+     on PHCTN=PLCTN
> >      C+   left outer join DGF4
> >      C+     on F4PROD=PLPRD
> >      C+     and F4CMP=PHCMP
> >      C+     and F4FAC=PHFAC
> >      C+   left outer join HARF
> >      C+     on HARCOD=F4HARM
> >      C+   left outer join DGF5
> >      C+     on F5CMP=PHCMP
> >      C+     and F5Fac=PHFAC
> >      C+     and F5PROD=PLPRD
> >      C+   left outer join
> >      C+      (select F2FRUM, min(F2TOUM) as F2TOUM, min(F2FACT) as
> F2FACT
> >      C+        from DGF2 group by F2FRUM) DGF2
> >      C+     on F2FRUM=F5IUM
> >      C+   left outer join DGFK
> >      C+     on FKHARM=F4SUBH
> >      C+     and FKFAMN=F4FAMN
> >      C+   left outer join DGFL
> >      C+     on FLHARM=F4SUBH
> >      C+
> >      C+   where PHCONS=:Cons
> >      C+
> >      C+   group by PLCTN, PLPRD
> >      C+ order by PLCTN, PLPRD
>
>
> -- 
> 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.
>
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.