>>I do not blindly trust SQL (or my ability at using it), but I use it extensively. I try to test the output of SQL queries in some other way that using SQL before they go in production. I did have a lot of surprises, but almost always found a way out (in our example: use the first statement).
>
>What happen everythings fails, e.g. a query such as
>

>select * from db1, db2 where (fld2a=fld2b) AND (trim(fld1a)=trim(fld1b)) AND (fld2a>2)
>

>
>I found that any integer expression other than in the first position causes unexpected results.
>When you get unanticipated results it should be becuse you've got something wrong, not that the SQL handler itself is wrong.
>
>>
>>I find it curious that sometimes you need to pad char fields to avoid truncation of the result set, but may be somebody more knowledgeable can argue that it is normal behavior...
>
>The problem is that writing a 3 char string to a 10 char field results in right padding with spaces, so if you do a comparison between two 10 char fields & you don't want an EXACT match, then you've got to trim the spaces :
>
>i.e.
>db1.fld1a = "ABC"
>when read back
>fld1a contains "ABC "
>
>"ABCD "="ABC " is FALSE
>"ABCD"="ABC" is TRUE (set exact off)
>
>hence the requirement for trimming
Forgot to put < pre > & < /pre > around the above to get the padding right, but I guess you got the idea