Re: Is this a bug w/ 4GL 4.10

In article <23jjncINNd9a@emory.mathcs.emory.edu> alan@po.den.mmc.com (Alan Popiel) writes: >aland@informix.com (Alan Denney) writes: >-> >->It's three-valued logic, working as expected. [1] >-> >->Saying (if charvar = "") is logically equivalent to (if charvar IS NULL). [2] >->We don't convert a value to NULL merely by clipping it, so for comparison >->purposes, the expression (blankvar clipped) still evaluates to a blank >->filed of zero length, conceptually. If you printed it, it should print >->nothing, but for comparison purposes, it still compares successfully >->to a blank field, e.g. >-> >->if x clipped = " " then -- note the blank between quotes [3] >-> display "x is blank" >-> end if >-> >->*Does* display the text as expected. >-> >[1] This may be expected at Informix, Inc., but it is certainly not obvious >from your documentation. > >[2] "" (a string of zero length) seems like it should be different from NULL >(which ought to be not-a-string). Informix can tell the difference between >an INTEGER equal to zero and a NULL value in place of the INTEGER. So why >not in this case? I think the real question here is: why does ("") denote NULL rather than spaces? I'm not really sure of the answer. Perhaps it is a "legacy" syntax; that is, in pre-SQL Ace and Perform, I don't think NULL was a valid keyword, and "" was the only way to specify it. That meaning would then have been maintained as a forward-compatibility issue. >[3] The purpose of CLIPPED is to *remove* all trailing blanks. Therefore, it >seems peculiar that the result of (" " CLIPPED) should match " ", which can >be thought of as an empty string followed by a trailing blank. If that is so, >does "XYZ" match "XYZ "? Actually, yes. Think of what an alphanumeric compare of differing-length strings really means: step 1: pad the shorter field with trailing blanks to the same length as the longer string; step 2: compare. > I know that the Informix engines are less sensitive >to trailing blanks than, say, Oracle engines, which are adamant that trailing >blanks are significant; but how does 4GL treat such blanks? For comparisons of fixed-length character strings, they are not significant. In what way are you claiming that the tools differ from the engines in this regard? >H | R. Alan Popiel |__________________ Alan -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland "I was thinking about the new phone I bought. The first thing I did was to hit 'Redial'. The phone had a nervous breakdown." -- Steven Wright