Yeah Gunnar, but I would hate to go back to the old times, at least as far as
computers are concerned.
I remember when it took 24 hours to reload a 1MB database over a network.
I use the single fetch for exactly the reason you present.
Having one place to change is far less risky that having to remember to change
2.
But, to be fair, I thought I would make a test to see exactly what the hit was
to have two variable tests, vs one.
My results for a 100,000 iteration loop:
RBDOS 2 tests = 19 seconds
RBDOS 1 test = 13 seconds
RBWIN 2 tests = 4.5 seconds
RBWIN 1 test = 3.5 seconds
In the grand scheme of things, neither time difference is significant, since
including a fetch in the loop would totally swamp these trivial differences.
Here is my code:
set time for HH:MM:SS.sss
set var vint int
set var vStartInt Int = 100000
set var vStartTime TIME
set var vEndTime TIME
set var vSeconds Double
set var vStartTime = .#time
set var vint = .vStartInt
while 1 = 1 then
set var vint = (.vint -1)
if vint = 0 then
break
endif
endw
set var vEndTime = .#time
set var vSeconds = ((.vEndTime - .vStartTime)/1000)
wri .vSeconds
set var vStartTime = .#time
set var vint = .vStartInt
while vInt > 0 then
set var vint = (.vint -1)
endw
set var vEndTime = .#time
set var vSeconds = ((.vEndTime - .vStartTime)/1000)
wri .vSeconds
return
Dennis McGrath
________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of Gunnar Ekblad
Sent: Monday, June 15, 2009 2:07 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Cursor operation continues after end of data
Karen and others
I have been there, I have forgotten to change the second fetch.
So I just wonder what happend to nice easy understandable powerful SET POINTER
In those days (long forgotten) there was only need for 1 and all colums was
there.
I know I am old fashioned but there are cases when old times where beter then
DECLARE CURSOR
Gunnar Ekblad
-----Ursprungligt meddelande-----
Från: [email protected] [mailto:[email protected]] För [email protected]
Skickat: den 15 juni 2009 17:16
Till: RBASE-L Mailing List
Ämne: [RBASE-L] - Re: Cursor operation continues after end of data
Mike: You will never convince me that your way is better!! ;-)
I suppose there is a "double test" -- it does have to figure out each
loop if 1 is still = 1 ... But the best advantage is that there is only
ONE fetch. Come on... how many times have you added a column
to the declare statement and changed one fetch but forgot to change
the other fetch?????
Karen
If I were traversing a large dataset, I would rather use two fetches with
only one test for TRUE per loop instead of the obvious double test in this
format. So as a matter of course, large dataset or small, I stick with the
double fetch for standardization.
----- Original Message -----
From: "Dennis McGrath" <[email protected]>
To: "RBASE-L Mailing List" <[email protected]>
Sent: Friday, June 12, 2009 10:06 AM
Subject: [RBASE-L] - Re: Cursor operation continues after end of data
This is my personal preference too.
There is only one fetch to maintain, and the program flow is totally
unambiguous.
Dennis McGrath
________________________________
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Thursday, June 11, 2009 4:56 PM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: Cursor operation continues after end of data
Randy: Marc is right. It is evaluating true because it is looking at the
LAST command that's before your while loop. FWIW, I never use the "WHILE
SQLCODE <>100 THEN" structure because of that. I just don't trust to know
what command it is evaluating. I always do this:
DECLARE c1 CURSOR FOR SELECT .....
OPEN c1
WHILE 1 = 1 THEN
FETCH c1 INTO vars....
IF SQLCODE = 100 THEN
BREAK
ENDIF
ENDWHILE
