Hi, The query processor defines "WITH fieldname" that has no relational operator as a test for non-null so this is not the same as a true/false test. Again, as far as I know, this is the same across all multivalue products.
Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson Sent: 31 July 2013 11:46 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
