> Three issues that come to mind: You've really only listed two issues.
> Cannot access transaction errors because a coldfusion exception is thrown so > any validation exceptions must be > handled through cftry/cfcatch instead of the CFSTOREDPROC. If en error occurs > in SQL, it means coldfusion throws > an error too. This is (a) in keeping with how CF deals with database errors generally, and (b) pretty much ideal. What would you suggest CFSTOREDPROC do, other than swallow the database error? There's no place within CFSTOREDPROC for additional conditional processing, really, so why not use exceptions? Of course, you can use the database-specific attributes within CFCATCH to figure out how to respond. > dbvarname is completely useless. It would be nice to be able to send values > across out of order or not send a value > if it is not needed (NULL). It would also be nice to have those values in the > debugging to reference. My understanding is that this is a limitation in JDBC, although I can't really say I've verified that for myself. But yeah, it would be nice to send name-value pairs. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:325744 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
