Title: Message
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Taco Fleur
Sent: Monday, 29 December 2003 11:22 AM
To: CFAussie Mailing List
Subject: [cfaussie] RE: SP Debugging

Hi Nick,
 
>  What I do with SP's is use a try catch statement and an error template. 
 
I have a global error catching template, but it will still give me insufficient information.
 
>  I create a string that contains the SP Call and display it along with the full error in the error template.  
Does that mean you basically recreate the cfstoredproc syntax to basic SQL, so you have two versions to maintain ;-) 
 
 
 
I only do this for Debugging in other words if it don't work. Of course all my queries work first time every time so I don't do it often :). I've found that often the only way to figure out what's going on is to get the exact string of the SP Call made in the Stored Proc.
 
 
 
>  I f there is an error I copy the SP call to Query Analyser and run it there. QA gives you a lot of detail about what failed.  
That's basically what I do, I just go into QA, get the SP up, right-click it and select debug, enter all the values that I dumped with cfdump and run it, it all works fine.
I found the problem BTW, I had a condition where the SP might need to pass params as null, I did this like;
 
<cfif listFindNoCase("physical,both", session.contactNew.form["type"])>
    pass with value
<cfelse>
    pass them as null
 </cfif>
 
While I kept adding params passed in the true statement I did not add the empty params in the false part of the statement.
This one kept me busy for a while, the error returned from CF should be a bit more clear, if it showed me the offending value it could not convert I would have debugged this one a long time ago. 
 
 
 
If for some reason you don't pass the params in the order specified in the SP then you'll get an error. For some reason the SP Call made by cfstoredproc seems to pass the values but not the param names I.E.
sprocName #var1#,#var2#,#var3#. If you miss param 1 or 2 then you get funny results as call will look like  sprocName #var1#,#var3# and Var 3 will be inserted into Param 2. In QA if you use the call sprocName @p_Var1=#var1#,@p_Var3=#var3#,@p_Var2=#var2# It will work if you do the equivalent in cfstoredproc and the SP has the variables declared in order you get odd results.
 
 
 
One last question, how you are doing debugging, does that give you any more info, like the offending value, I don't think it does, but I better check? 
 
Not sure I understand the question. 
 
Cheers,
 
Taco Fleur
www.tacofleur.com
 
 
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia
http://www.mxdu.com/ + 24-25 February, 2004

Reply via email to