It looks like OpenBD handles things fairly well on its own, with some caveats.
Given: tblTest id: 1 chrText: "hello world" intNum: 123 chrNull: [null] (varchar field) intNull: [null] (int(10) field) <cfquery name="q"...>SELECT * FROM tblTest;</cfquery> Running QoQs on "q": SELECT q.intNum + q.chrText AS chrStuff FROM q; returns "123hello world" SELECT q.intNum + q.chrNull AS chrStuff FROM q; returns "123" SELECT q.intNum + q.intNum AS chrStuff FROM q; returns "246" SELECT q.intNum + q.intNum + q.chrText FROM q; returns "123123hello world" So all of that is as expected. When we start mixing in [Null] we get some inconsistent behaviour: SELECT q.intNum + q.intNum + q.intNULL FROM q; returns "246" It looks like OpenBD converts a [Null] in an INT field to 0. SELECT q.intNum + q.intNum + q.chrNULL FROM q; ALSO returns "246" So OpenBD converts a [Null] in a VARCHAR field to 0 as well. What's interesting is SELECT q.intNum + q.intNum + q.chrNull + ' ' AS chrStuff FROM q; also returns "246" -- the trailing blank space gets treated as a 0 (or trimmed off) but SELECT q.intNum + ' ' + q.intNum AS chrStuff FROM q; returns "123 123" Leading spaces likewise trigger the string behaviour: SELECT ' ' + q.intNum + q.intNum AS chrStuff FROM q; returns " 123123" OpenBD seems to follow these rules parenthetically as well. SELECT (q.intNum + q.intNum) + q.chrNull + q.chrText AS chrStuff FROM q; returns "246hello world" So, that was interesting. -- official tag/function reference: http://openbd.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
