> >��2. the second program i tried also failed with a (somewhat less)
> >��cryptic error on a </cfhttp> tag
> >
> I believe there is a documented compatibility difference in regard to
> cfhttp. See the compatibility guide.
Yes, it is documented -- that's how I found the problem -- but it was
reported as a problem with the </cfhttp> tag.
>
> >��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.
Don't know why -- it's BD's treatment of a null field that's the prob
-- here it is though:
SELECT
C.Name AS Category,
I.EstateItemID,
I.EstateItemIID,
I.CreateDateTime,
I.CategoryID,
I.GroupName,
I.Name,
I.Description,
I.Comment,
I.PurchaseDate,
I.OriginalCost,
I.AppraisalDate,
I.AppraisalValue,
I.EstimatedValue,
I.ThumbNailURL,
I.BlowUPURL,
I.Active
FROM Category C Left Join EstateItem I Using(CategoryID)
WHERE C.Name = 'Jewelry'
ORDER BY I.GroupName, I.Name
> >��136: <cfoutput query="getMySQLEstateItem">
> >��137:���<cfif GroupName NEQ variables.GroupName>
> Even though I don't think it has anything to do with the problem, that
> cfif really needs to be changed.
what's wrong with it?
> >��I was able to work around this by changing the nulls in the db to
> 0.
> >
> Clearly, you shouldn't have to do that.
I agree -- that's why I say the prob is BD's inadequate support for SQL
constructs.
> >��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.
I was surprised, too!
I tried it with get and a closing tag -- above error
I cfhttpparam, get and no closing tag -- different error.
> >��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.
It must be a bug!
> > 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.
Fair enough!
> >��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.
It does not for a MySQL decimal field.
> 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.
I may do that but I don't have a lot of free time at the moment.
Others have stated that NewAtlanta is quite responsive -- just thought
I'd post the probs here in case other CFMX users of BD had similar
experiences.
Thanks for your comments.
Dick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
