Gunnar, I can't even remember the syntax for SET POINTER.
I've learned standard is best just because being retro wastes your time, eventually. I think we all have our pet gripes about one syntax or another, but you can't fight City Hall as they say. Dennis ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Gunnar Ekblad Sent: Monday, June 15, 2009 2:53 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Cursor operation continues after end of data Dennis I agree the old times are old times. What I dont understand is why SET POINTER cant work in the new times. I must say in owerall I prefer the new times even if I still use dos version on ocation where SET POINTER still works Gunnar Ekblad -----Ursprungligt meddelande----- Från: [email protected] [mailto:[email protected]] För Dennis McGrath Skickat: den 15 juni 2009 21:29 Till: RBASE-L Mailing List Ämne: [RBASE-L] - Re: Cursor operation continues after end of data 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
