> I always had the impression that we invented the > language this side of the pond so you lot really > ought to use the correct spelling <g>.
Once, when I was a young teenager, we were visiting relatives in Denmark where I was told I spoke "American", not "English". Which makes sense since the stranger I was talking with spoke better English than I did :( On Tue, May 22, 2012 at 7:27 AM, Dennis McGrath <[email protected]>wrote: > Having spent a week in northeastern Scotland, if you asked me to spell > things your way I would reply, "I canna deit!" > > Dennis McGrath > [email protected] > [email protected] > > > > On Tue, May 22, 2012 at 2:22 PM, Stephen Markson <[email protected]> wrote: > >> Hear, hear! >> >> Regards, >> >> Stephen Markson >> The Pharmacy Examining Board of Canada (where some us try to use the >> Queen’s English) >> 416.979.2431 x251 >> >> From: [email protected] [mailto:[email protected]] On Behalf Of Alastair >> Burr >> Sent: Saturday, May 19, 2012 2:03 PM >> To: RBASE-L Mailing List >> Subject: [RBASE-L] - Re: Difference between "select into" and "setvar" >> >> Bernie, >> >> Perhaps if you’d used an S instead of a Z I wouldn’t have turned purple >> with rage <g> – I always had the impression that we invented the language >> this side of the pond so you lot really ought to use the correct spelling >> <g>. >> >> (And, yes, I do know that I’m taking liberties with where the origins >> were but only for comic effect!! And you can spell it how you like for all >> I care. Besides which, Dennis probably just had little wayward piggies on >> his keybroad.) >> >> Regards, >> Alastair – in England – where English comes from!! >> >> >> >> >> From: Bernard Lis >> Sent: Friday, May 18, 2012 8:56 PM >> To: RBASE-L Mailing List >> Subject: [RBASE-L] - Re: Difference between "select into" and "setvar" >> >> 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] >> >> >> >
