tracker issue : CF-3918813

select a category, or use search below
(searches all categories and all time range)
Title:

ColdFusion 11 patch 3 breaks applications due to changing default behavior for dbvarname in cfprocparam

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/Duplicate

Reporter/Name(from Bugbase): Rob Weaver / Rob Weaver (Rob Weaver)

Created: 01/09/2015

Components: Database

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / Most users will encounter

Locale/System: English / Win 2012 Server x64

Vote Count: 0

Duplicate ID:	CF-3865064

Problem Description:

Installing CF11 patch 3 breaks our application because we have dbvarname values that were previously ignored. The documentation states that a JVM setting is required to turn on the dbvarname (-Dcoldfusion.dbvarDependants={dsn1, dsn2}) but that doesn't appear to be true any longer.

Steps to Reproduce:

    1. Create a procedure to be called that has a named parameter.

           PROCEDURE new_session (
              sido            OUT   VARCHAR2,
              usernamex             VARCHAR2,
              passwordx             VARCHAR2,
              ip_addressx           VARCHAR2,
              rand_intx             INTEGER,
              app_idx               NUMBER,
              check_ipx             NUMBER,
              pwd_requiredx         NUMBER DEFAULT 1
          );

    2. Use that procedure in a cfprocparam with some parameter name misspelled:

  	<cfstoredproc procedure="td_session_pkg.new_session" datasource="#application.datasource#">
  		<cfprocparam type="Out" cfsqltype="CF_SQL_CHAR" dbvarname="SID_xo" variable="sid">
  		<cfprocparam type="In" cfsqltype="CF_SQL_CHAR" dbvarname="USERNAMEx" value="#arguments.username#">
  		<cfprocparam type="In" cfsqltype="CF_SQL_CHAR" dbvarname="PASSWORDx" value="#arguments.password#">
  		<cfprocparam type="In" cfsqltype="CF_SQL_CHAR" dbvarname="IP_ADDRESSx" value="#cgi.remote_addr#">
  		<cfprocparam type="In" cfsqltype="CF_SQL_INTEGER" dbvarname="RAND_INTx" value="#rand_int#">
  		<cfprocparam type="In" cfsqltype="CF_SQL_INTEGER" dbvarname="APP_IDx" value="#application.app_id#">
  		<cfprocparam type="In" cfsqltype="CF_SQL_INTEGER" dbvarname="CHECK_IPx" value="1">
			<cfprocparam type="In" cfsqltype="CF_SQL_INTEGER" dbvarname="pwd_requiredx" value="#pwdRequired#">
  	</cfstoredproc>

Actual Result:

         Before patch 3 this would work because the dbvarname was being ignored.

         After patch 3, we get an exception:

                    Error Executing Database Query.

                    ORA-06550: line 1, column 34: PLS-00201: identifier 'SID_XO' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored


Expected Result:

       Same as prior to patch 3, dbvarname should be ignored unless we set the value as indicated in the documentation at https://wikidocs.adobe.com/wiki/display/coldfusionen/cfprocparam

Any Workarounds:

       The work around for us is to remove thousands of dbvarname parameters, or to go through every single one and verify against the database. At this point our application will break if we update the server with patch 3

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3918813

External Customer Info:
External Company:  
External Customer Name: TheraRob
External Customer Email:  
External Test Config: CF 11 on Windows 2012 R2, IIS.

Attachments:

Comments:

This is NOT the same as bug #CF-3865064 - this is regarding the dbvarname parameter actually being used when the system property coldfusion.dbvarDependants has not been set. Prior to patch 3, the variables were being passed to the procedure in the order they are defined. After patch 3 they are being passed by variable name, and therefore (at least with Oracle) must match the name of the parameter of the procedure. I need a fix, or a way to set the system property coldfusion.dbvarDependants that will disable the pas by name behavior.
Comment by External U.
9024 | January 12, 2015 09:04:11 AM GMT
Ugh. So you have poorly written code that relied on an obsolete tag attribute being ignored (which hurt many enterprise devs), and now that the attribute's functionality has been restored, you want to blame Adobe for *your* code? As painful as fixing your code may be, you just need to do it and move on.
Comment by External U.
9025 | January 13, 2015 09:41:39 AM GMT