Re: Is this a bug w/ 4GL 4.10

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? [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 "? 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? O ___________________________ Regards, H | R. Alan Popiel |__________________ Alan H | Martin Marietta, Tech Ops | Internet: |_________________________ H | P.O. Box 179, M/S 5422 | alan@den.mmc.com | / H | Denver, CO 80201-0179 USA | Voice: | Std disclaimers apply./ H |___________________________| 303-977-9998 | ( H (_____________________| (But you knew that!) \\ H (___________________________\\