Yes, in all cases, I think BD's behaviour to be more desirable, but that doesn't change the fact that CFMX is the definition of the CFML language, and so the discrepancies have to be deemed bugs in BD. At best they could be BD extensions, but to my knowledge, none of them are documented as language extensions. And in either case, they're incompatibilities between the two CFML runtimes, and that was really the point of my post.

Nope, sure didn't. I was moving an app to another CF server when I ran across the issues. The stuff will continue to run on BD, but it probably won't ever be updated again, as the CF7-compatible version is now the main branch.

Barry,

There was a long thread about this (and a few other things on CF-Talk a bit ago. You can hit the houseoffusion.com archives if you missed it. I don't believe that BD has any official support for nulls, but I suspect they might have some bugs in their implementation that exposes underlying machinery that does support nulls (since it's written in Java). So it's definitely buggy behaviour, but not necessarily undesirable behaviour, at least if it were documented and supported.

Barney, can you elaborate?

I'm just starting to think that returning NULL for no data is a much better idea (esp for the numeric example you mentioned) than some arbitary sentinal value like "0″ or "-1″ or "".

Sure, it can be worked around but only in context of what's required at the time (zero, empty string, throw an error). NULL still means "no data" and if CF could test for NULLs then I'm sure it might help.

So how far does BD go with returning nulls?

What would you like to see for CF?

cheers
barry.b