Copy link to clipboard
Copied
ColdFusion 11 Details:
Server Details | |
Server Product | ColdFusion |
Version | 11,0,03,292480 |
Tomcat Version | 7.0.54.0 |
Edition | Developer |
Operating System | Windows 8 |
OS Version | 6.2 |
Update Level | C:/ColdFusion11/cfusion/lib/updates/chf11000003.jar |
Adobe Driver Version | 5.1.3 (Build 000094) |
Sample error:
queryError | [Macromedia][SQLServer JDBC Driver][SQLServer]Procedure or function 'ListClientDPReceiptFormat' expects parameter '@idCient', which was not supplied. |
where | (param 1) = [type='IN', class='java.lang.Integer', value='4', sqltype='CF_SQL_INTEGER'] |
Stored Procedure:
<CFSTOREDPROC procedure="ListClientDPReceiptFormat"> | ||
<CFPROCPARAM TYPE="IN" DBVARNAME="@idClient" VALUE="#Request.Client.Id#" CFSQLTYPE="CF_SQL_INTEGER"> | ||
<CFPROCRESULT NAME="qryDPReceiptFormats"> | ||
</CFSTOREDPROC> |
This stored procedure and others like it worked fine until CF 11 update 3 was applied.
Thanks!
There seems to be a typo here. Can you clarify...
The error "[Macromedia][SQLServer JDBC Driver][SQLServer]Procedure or function 'ListClientDPReceiptFormat' expects parameter '@idCient', which was not supplied." has the parameter defined as @idCient but your cfprocparam has the dbvarname = "@idClient".
These are spelt differently.
I think this maybe related to what is mentioned in this bug - Bug#3865064 - ColdFusion 11 Update 3 Breaks CFPROCRESULT
Adam Cameron notes:
...
"Basically, then, this is a cas
Copy link to clipboard
Copied
There seems to be a typo here. Can you clarify...
The error "[Macromedia][SQLServer JDBC Driver][SQLServer]Procedure or function 'ListClientDPReceiptFormat' expects parameter '@idCient', which was not supplied." has the parameter defined as @idCient but your cfprocparam has the dbvarname = "@idClient".
These are spelt differently.
I think this maybe related to what is mentioned in this bug - Bug#3865064 - ColdFusion 11 Update 3 Breaks CFPROCRESULT
Adam Cameron notes:
"Basically, then, this is a case of the code in question was incorrect, but the user was getting away with it because the DBVARNAME was being ignored. Now that it's not being ignored, the code actually has to be legit ;-). Fair enough, In that case."