> cryptic error on a </cfhttp> tag
>
I believe there is a documented compatibility difference in regard to
cfhttp. See the compatibility guide.
> Now I became concerned -- these programs have been running without
> problems for over a year.
>
They have been running on a different application server. It should be
common knowledge that no two application servers will be exactly the
same in implementation, so the results on one are meaningless on
another. This is not unique to the CF world.
> 1, was an error on a cfquery��caused by the fact that a decimal field
> contained a null rather than a 0.��Here's the error:
>
It would be great to see your SQL.
> 133: <cfset variables.GroupTotalRelativeValue = 0>
> 134: <cfset variables.GroupName = getMySQLEstateItem.GroupName>
> 135:
> 136: <cfoutput query="getMySQLEstateItem">
> 137:���<cfif GroupName NEQ variables.GroupName>
> ^ Snippet from underlying CFML source
> -------------------------------------------------
>
Even though I don't think it has anything to do with the problem, that
cfif really needs to be changed.
> I was able to work around this by changing the nulls in the db to 0.
>
Clearly, you shouldn't have to do that.
> 2. The second problem was caused by a cfhttp method=get.��BD does not
> allow a closing tag nor cfhttparam tags on gets.
>
Reading BD's docs certainly implies that cfhttparam can't be used with
method=get, but that seems like a mistake in the docs. I can't imagine
they didn't think of supporting the sending of cookies for get
requests. I'll try and get an answer on that Monday as that is a pretty
serious oversight.
> The BD support for SQL is inadequate -- an SQL NULL is typeless -- it
> can apply to any field type -- BD has no business rejecting a null for
> any field type.
>
BD certainly allows nulls, so either you are encountering a bug or the
real problem is hidden.
> BD is incompatible with CFML in several areas -- the cfhttp
> differences
> are key to many of my applications.
> In my opinion, the "challenger to the throne" must equal or exceed the
> capabilities of the current "ruler".
>
I don't believe BD is currently a challenger to the throne, but an
alternative CFML implementation that offers important benefits for
specific applications. See
http://bluedragon.blog-city.com/read/601768.htm for more on that.
> BD is not sufficiently compatible with CFML.
>
That is not the norm even if it is the true in your case.
> BD does not fully support SQL constructs.
>
It does indeed, see my earlier statements.
> These deficiencies outweigh any BD advantages -- in all good
> conscience
> I cannot recommend BD to my clients.
>
That may be, but let me offer an alternative. Instead, share your
findings with New Atlanta. They may indeed fix your problems such that
you can recommend it. In fact, it is even possible the problems you ran
into are already documented bugs that are going to be fixed by the
final release. I mean you are testing against a product that still has
bugs in it; it's an RC.
-Matt
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
