First, some background.
dbvarname is an attribute for cfprocparam to specify named parameters while calling a stored procedure. For details refer https://wikidocs.adobe.com/wiki/display/coldfusionen/cfprocparam
Versions prior to ColdFusion5 had support for dbvarname. This was deprecated in ColdFusion MX, brought back in 7.0.1 and deprecated again in 7.0.2. The reason was the lack of proper support from multiple jdbc drivers. Since then, this was a major ask among ColdFusion users.
ColdFusion 11 brought this attribute back from the dead. It was disabled by default with a flag to enable it. ColdFusion 11 update 3 enabled it by default. Databases need a variable prefix for named parameters. (eg:- “:” for Oracle and “@” for SQLServer). If the database is SQLServer, it should be dbvarname = “@param1”. This will break applications which were using this attribute without the prefix because this attribute was being completely ignored in prior versions. So to give some time for customers who don’t want to change their code, in update 4 we introduced a flag to disable dbvarname.
-Dcoldfusion.ignoredbvarname=true jvm flag can be used to disable dbvarname attribute. This flag is only for CF11 and not for later versions.
Having to change lot of code is not pleasant but we believe that is the way forward.
Readers should note that the jvm arg offered above (to revert the behavior/allow backward compatibility in cf11) was NOT carried forward into cf2016 and beyond.
I have a question regarding this topic. I have a block of Custom Tags that were written for and still running on Coldfusion 10. As such they were written without the variable prefix for named parameters (in my case ‘:’ for an Oracle DB. We’re about to start running Coldfusion 2018 and are planning to use those same custom tags.
As a bit of testing, I have taken a couple of our less important tags and placed the variable prefix in them just to see if they will run on both CF10 and CF2018. I have found that they do run on both versions of Coldfusion. That is to say that CF2018 requires the ‘:’ prefix to run, and it appears that for CF10, while it doesn’t require the ‘:’ prefix, it is running fine with the ‘:’ prefix in there.
My question is this: is this to be expected? Is there any reason this might break in the future?
No, it is not expected to change.
Charlie,
thanks for the response. Since CF10 will run the custom tags with the ‘:’ prefix (event though it isn’t required) is there any other reason to not re-write the custom tags to make use of them? Is there some hit to performance?
If so, I may write keep versions in separate directories: one with the prefix and one without, and have the custom tags run out of each of them separately.
I’d think there’s no problem, but do test, and let folks know how it goes. 🙂
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
