Copy link to clipboard
Copied
My organization recently updated from CF2018 to CF2021 and I've encountered some odd behavior for which Google has been unable to provide an answer. The following line of code started throwing an error:
<cfset queryName.currentRow += queryName2.numberOfLines>
The error is:
There is a problem in the column mappings specified in the columnMap structure.The query attribute input does not contain any column by the name of currentRow.
Even a simpler test throws the same error:
<cfset queryName.currentRow = '10'>
I cannot figure out if this was an intentional change between CF2018 and CF2021 or a bug. I do know that it was not throwing an error in CF2018. Has anyone encountered something like this?
ColdFusion 2021 is actually giving you a hint. QueryName.currentRow is actually a system property in ColdFusion. As such it already has a value. You can confirm this using the following line of code:
<p>Row number = <cfoutput>#queryName.currentRow#</cfoutput></p>
It is therefore wrong for the programmer to assign a value to queryName.currentRow. It just might be that you're seeing the error now because CF2021 is in general more accurate than CF2018.
Copy link to clipboard
Copied
ColdFusion 2021 is actually giving you a hint. QueryName.currentRow is actually a system property in ColdFusion. As such it already has a value. You can confirm this using the following line of code:
<p>Row number = <cfoutput>#queryName.currentRow#</cfoutput></p>
It is therefore wrong for the programmer to assign a value to queryName.currentRow. It just might be that you're seeing the error now because CF2021 is in general more accurate than CF2018.
Copy link to clipboard
Copied
@BKBK Agree with your points.
My confusion stemmed from the fact that the code in my example worked fine without error (even if it was not correct) until CF was upgraded. If this was a flaw in CF2018 that was fixed in CF2021, I couldn't find anything in the release notes stating that.
If the error I'm getting now IS actually the intended behavior, I'm willing to accept that and implement a workaround to what my example is attempting to accomplish.
Copy link to clipboard
Copied
Hi @pauljarema ,
Your confusion is understandable. ColdFusion 2018 should have flagged the assignment
<cfset queryName.currentRow = '10'>
as an error. In any case, that line would have produced incorrect results! 😞
Although CF2018 tolerates the line, the value of queryName.currentRow is not necessarily 10, as you would expect. If the current row is 1, then the value of queryName.currentRow will be 1. Irrespective of the assignment. In other words, the 10 is ignored.
That is the behaviour in CF10, CF11, CF2016 and CF2018. In fact, in these CF versions, the following code works, with 1 as output.
<cfscript>
queryName = queryNew("id,name","Integer,Varchar",
[
{id=1,name="One"},
{id=2,name="Two"},
{id=3,name="Three"}
]);
queryName.currentrow="abracadabra";
writedump(queryName.currentrow);
</cfscript>
Go to TryCF and see for yourself.
Copy link to clipboard
Copied
Thank you all for the explanation of the CF2021 issue explained in this thread. I am experiencing the same issue. I just performed a simple query, tried to set the recordcount afterward, and got the same error.
My question is about whether there might be a JVM argument to revert this back to the way things worked in CF2018, or some other global fix. Our codebase appears to set recordcount manually upwards of 90 times throughout, and our application is already live. Any info would be greatly appreciated.
Copy link to clipboard
Copied
@Dordrecht , Could you share the code and the stacktrace of the error?
Copy link to clipboard
Copied
Hi, BKBK.
The error is exactly the same as pauljarema's above, and I've tested it and confirmed that the issue is due to setting the recordcount of query results to zero with the cfset tag. Previous coders of our app have code that sets query recordcounts to 0 in cases where the query results don't matter, followed by conditionals that take action only if the recordcount is greater than 0.
Recoding all of the instances to use other variables would be a big task, with a great deal of testing required, which is not desired because the ColdFusion app is being rewritten in a different language over the coming year anyway.
Copy link to clipboard
Copied
The best short-term solution hack I can think of, if nobody here has a better solution, is to code a method in our global utilities object...
<cffunction name="ZeroRecQuery" returntype="query" output="false">
<cfquery name="getZeroRows">
SELECT 1 AS dummy WHERE 1 = 2
</cfquery>
<cfreturn getZeroRows>
</cffunction>
Then replace a command like the following:
<cfset myQuery.RecordCount = 0>
with the following:
<cfset myQuery = request.utils.ZeroRecQuery()>
This works because it replaces the whole query. It's a horrible hack, but it has the benefit of beig highly reliable and a line-for-line replacement. Still, I'd like to avoid doing that if there's a better solution.
Copy link to clipboard
Copied
In view of your code,
<cfset myQuery.RecordCount = 0>
I would give you the same feedback that I gave Pauljarema.
ColdFusion is actually giving you a hint. QueryName.recordcount is actually a system property in ColdFusion. As such it already has a value. You can confirm this using the following line of code:
<p>Number of rows = <cfoutput>#queryName.recordcount#</cfoutput></p>
It would therefore be wrong for the programmer to be able to assign a value to queryX.recordcount. That follows from the fact that queryX is an object and recordcount is a property of the object.
Therefore, you could reset the recordcount to 0 by just resetting the query. The following will give you a recordcount of 0:
<!--- Reset the query --->
<cfset myQuery = queryNew("", "")>
myQuery.recordcount: <cfoutput>#myQuery.recordcount#</cfoutput>
Copy link to clipboard
Copied
BKBK
Yes, there is no confusion as to why the existing code doesn't work. The purpose of my post was to find an easy workaround, such as a JVM argument. Your use of QueryNew() is more efficient than actually doing a dummy query, so that is the going solution if nobody else has a quick fix. Thanks