> I'm pretty sure it's the order that is hanging it up. I > have used > cfstoredproc in other places on our servers and it works > just fine.
> It's pretty dissapointing that this seems to be a > "feature" or "bug" or > whatever you want to call it that MM is ignoring. What > happens when you > want to skip parameters in a dynamic statement like I was > doing, I guess you > have to revert to cfquery? Or you have to include all the parameters you wanted to skip ... Which means you can't allow the stored procedure to use its defaults. In my case most of my stored procedures use NULL for any defaults, so passing null="yes" in the <cfstoredproc> is equivalent, however, if I used "bilbo" as a default for instance, I'd have to pass "bilbo" as the value, which thoroughly defeats the purpose of having a default in my stored procedure and makes my job that much harder if that "default" value ever changes. > Also, what is the deal with cfquery in CFMX? I've just > finally got CFMX > installed tonight for the first time. Our website which > is probably 95% > cfquery vs. cfstoredproc seems to be working just fine. > For a datasource I > just chose SQL Server from the list of datasource types > when I created it, I > think this means I'm using the JDBC driver? Either way, > all of our stored > procedure calls that are made in cfquery tags seem to be > working fine. Hmmm... do many of your stored procedures return a recordset? That's the only issue really, so if you only use the stored procs to perform inserts and updates and aren't concerned with getting a recordset back, there wouldn't be any reason to notice the difference. Otherwise, you may be using the ODBC socket -- I wouldn't know, I've been too busy with recent updates and preparing for MX to actually install MX and work with it much. I suppose it's possible MM could have found a way to change the behavior with the JDBC drivers in the recent MX update though again I wouldn't know. > Personally, I have always preferred the cfquery tag over > the cfstoredproc > for the simple reason that you get real error messages > back and not just > "Unknown Data Access Error". Not to mention all that extra typing. :) Though iirc, it does have some other advantages in that I believe it's supposed to help speed up processing of stored procedures ( I wonder if this is done by not naming parameters ;P ) and it insulates the procedure from unlikely sql insertion attacks and issues with data insertion, like the \ on MySQL ( although current versions of MySQL don't support stored procedures ) being a special character that <cfquery> doesn't know to account for. Of course, much of this can also be accomplished with <cfqueryparam> in a stored procedure called with <cfquery> so my biggest gripes are the lack of ability to use db defined defaults and the fact that it's completely undocumented anywhere on MM's site ( actually the documentation says that the dbvarname attribute is supposed to be the name of the parameter in the stored procedure, which you might be able to weasel out of saying is an out and out lie, but it's certainly seems to indicate that the order of parameters shouldn't matter ) and since I may not necessarily be the only developer who ever touches my code there's a good chance at some point that I'm going to have to field technical support calls or emails in which I'll have to explain this whole debacle over again. Isaac Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm
