|
> > 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. > >
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.