See below -- in purple ----- Original Message ----- From: Javier Valencia To: RBASE-L Mailing List Sent: Friday, May 18, 2012 3:00 PM Subject: [RBASE-L] - Re: Difference between "select into" and "setvar"
Dennis, I also use code similar to the one Stephen uses, and it does simplify things when you need to test a large number of variables. . I cannot think of a single reason why anyone would be offended by your post. All we offer here is opinion and in most cases, the benefit of our experiences. Opinions are just that, opinions; they represent our individual views of issues. I f have always found your posts informative and professional. I do not necessarily agree that variable indicators are code bloat, but I do not take offense just because we do not agree. The day that we all agree on everything, innovation disappears.I do not see that day coming any time soon. Javier, Javier Valencia, PE O: 913-829-0888 H: 913-397-9605 C: 913-915-3137 From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: Friday, May 18, 2012 3:59 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Difference between "select into" and "setvar" It seems that some users of this list find my statements below to be offensive. I appoligize (apologize) for any upset I may have caused. Does anyone out there have an example of how they use use the indicator variables after the data has been retrieved? I'm always interested in making my code more efficient, and would welcome any examples where this is acheived with indicator variables. Dennis McGrath [email protected] [email protected] On Thu, May 17, 2012 at 10:57 AM, Dennis McGrath <[email protected]> wrote: Now that we can easily turn off the message about a null value being returned, I find the indicator variables totally unnecessary code bloat. In the rbase environment, at least, If I want to know if a null is returned I can test the actual value returned. In over 25 years of progamming rbase, the only use I ever had for the indicator variables was to avoid throwing the error to make tracing easier. Dennis McGrath [email protected] [email protected]
