I was troubleshooting an issue with our ERP system's report output when i came across a strange behavior of the ABL code.
DEFINE PUBLIC PROPERTY TEXT AS CHARACTER NO-UNDO
SET (INPUT ip-text AS CHAR):
IF ip-text = ? THEN RETURN.
IF ip-text = "" THEN RETURN.
.
.
.
END SET.
This does not work as expected when the passed parameter contains only spaces.
In short it appears that in ABL, " " EQ "" is TRUE.
I know that in many cases this will not matter, but due to the nature of this module, it matters a great deal.
I had to change that check to IF LENGTH(ip-text) = 0 THEN RETURN, so I have resolved the issue for now, but I didn't know that the string comparison worked like that.
Nine times out of ten you benefit from this behavior, especially when you are looking for data in your database that accidentally has a trailing space. It would be very bad for performance if you had to put TRIM statements in all of your queries that involve character fields. So yes, every now and then this gives problems, like in your case, but generally speaking I think you should be glad with this functionality. It's not a bug; it's really a feature!
Documented behavior.
You can also use COMPARE function for that, but then who does remember all those 4GL functions :)
Nine times out of ten you benefit from this behavior, especially when you are looking for data in your database that accidentally has a trailing space. It would be very bad for performance if you had to put TRIM statements in all of your queries that involve character fields. So yes, every now and then this gives problems, like in your case, but generally speaking I think you should be glad with this functionality. It's not a bug; it's really a feature!
IF LENGTH(ip-text) = 0 THEN RETURN.
/Torben
I'd wager that since I was unaware of this behavior, there are probably tons of unnecessary TRIM() calls in our code.