UniData treats WITH fieldname as the equivalent of WITH fieldname > "". Both 1 and 0 would be selected, the empty string would not.
Larry Hiscock Western Computer Services -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: Wednesday, July 31, 2013 3:46 AM To: U2 Users List Subject: Re: [U2] What is true And then there's the query language: Suppose INVOICED field is supposed to be true or false. Stored as 1 or 0, but maybe left null in some records (We've all been there.): SELECT CUSTOMER WITH INVOICED If INVOICED is "0" or null, will said CUSTOMER record be selected or not? UV selects if "0", but excludes if null. Do all MV platforms work that way? On 7/31/2013 11:06 AM, Martin Phillips wrote: > Hi, > >> About the true/false thing, I always use 0 and 1 but I was chastised >> about that by a colleague recently, that it might not be completely >> cross-platform, and now I stutter on it every time I do that, >> wondering if I'm not really following a best practice > I seem to recall this same topic being discussed a year or two back, perhaps in a different group. > > In the multivalue world, the language definition says that anything that returns true/false returns 1 for true, 0 for false. > Anything that interprets a value as true/false treats zero and a null > string as false, everything else as true. This definition holds for > all multivalue products but not necessarily in other languages. Any new multivalue product that breaks this definition is probably doomed to failure because migration of existing applications would become a nightmare task. > > In our type variant world where we have no such thing as a Boolean data type, it is very easy to write statements such as > INVOICED = 1 > > Is INVOICED a Boolean variable, perhaps telling us in this case that > an invoice has been raised? Or, is it a state flag with multiple values for which this might be indicating a type of invoice that has been sent? There is no way for the reader to tell. > > At risk of starting a whole new discussion on programming style (and I > start form the viewpoint that there are many acceptable styles, it is > more important to be consistent), this is probably best resolved by > use of tokens. I have for many years held an interesting opinion that a program should never have any hard coded numeric values except perhaps zero, not that I adhere rigidly to my own opinion. The above line becomes something like > INVOICED = TRUE > or > INVOICED = INV.PDF > > Now, all is clear(er) to the reader. > > Prime Information introduced @FALSE and @TRUE as symbolic constants (0 > and 1 respectively) to avoid the need for our own equated tokens and several other multivalue products have followed this convention. > > Of course, nothing is ever completely black and white. As multivalue > Basic has developed, internal data types have gone beyond simply numbers and strings. If I write > IF FVAR THEN ... > where FVAR is a file variable, what do I expect this to do? The > language definition does not tell us but most multivalue products would give us a data type error of some sort because there is no rule for transforming a file variable to a Boolean value. > > > Martin Phillips > Ladybridge Systems Ltd > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England > +44 (0)1604-709200 > _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
