Recent change to dbvarname?

[Guest]

I am updating a CF10 server to CF2016. We ran into issues that stored procedures were not executing because the dbvarname attribute in the cfprocparam now required a colon to indicate an oracle database.

Originally, the error referred to a database failure of some kind (can't remember exactly what it is.) I prepended each dbvarname with a colon and it appeared to be working fine. Now, I have been given another piece of the website that hasn't had this done yet. While I was updating and doing some testing, it appeared that the error changed. The error is now

"The value '' cannot be converted to a number."

and it happens after the stored procedure. This error returns if dbvarname="", dbvarname="xxx", or dbvarname="(actual name)". The code works correctly when dbvarname has ANY value as long as a colon exists, including dbvarname=":" It appears that the actual value for dbvarname is being ignored and the cfprocparams are being treated positionally, if I switch the cfprocparam lines, it changes the output of the storedprocedure to something unexpected.

I checked the notes for the updates and didn't see anything about it, is it possible that this is a change that wasn't logged?

[WolfShade]

I did a quick Google search for just "dbvarname" and found this ColdFusionBlog post.

It was, then it wasn't, then it was again, then it wasn't again, now it is since CF11. 

HTH,

^ _ ^

[Guest]

Thank you for your reply,

yes, I am aware of the history of dbvarname, haha. This is a change in behavior between when I started the CF2016 upgrade about a month ago and now. When I did the last section of code, the error was a failure to execute a database procedure (or something like that) and it failed on the line number of the cfprocparam that included the dbvarname without the prepended colon. I inserted the colon and everything worked fine.

Time passed (about 1 month.)

I am now updating a new section of the website. I wanted to see what would happen if I ran different types of "wrong code." dbvarnames with null values, dbvarnames with colons and null values, dbvarnmes with wrong name, etc. It appears as though the colon is still required, but otherwise the dbvarname is being ignored. So, yes, dbvarname has quite the dramatic rollercoaster history, but I am talking very recent and the behavior is currently that it is NOT enabled (though it should be since CF11, as you point out.)