We are setting up Lucee in an Ubuntu container on an AWS EC2 server and we are getting 'key [xxx] does not exist" errors on our unscoped variables, despite having Local scope mode set to Classic, Cascading set to Standard, and Search resultsets enabled.
As an example, we have a query named “getLink”. There is code on the page that makes use of “#link#”, but it is not scoped as “#getLInk.link#”. As a result we get a “The key [LINK] does not exist” error. However, if I add “link=x” to the URL query string, then Lucee is able to find a value for the unscoped #link# variable and the error goes away.
The container is not one from docker hub, we have created our own container and the web files are stored outside the container.
Any thoughts on what is preventing the Search resultsets setting from working as expected and what we can do to fix this issue (other than going through our code and scoping every variable, of course)?
This is strange. But because when you use the URL.link and your unscoped variable #link# is getting populated, doesn’t that prove that it’s working? Did you do some further testing? Really hard to say. Do you have some code to share as a test case, so other of us cfml deveopers can try it on our local dev machines?
Thank you for your replies, I appreciate your time. Here is a very simple example that demonstrates the issue I’m having:
> <cfquery name="getLink" datasource="[DSN]">
> SELECT link
> FROM linkTable
> WHERE clientID = <cfqueryparam value="#url.clientID#" cfsqltype="cf_sql_integer">
> </cfquery>
>
> <cfoutput>
> #link#
> </cfoutput>
RESULT: The key [LINK] does not exist.
Zac, could you explain how the “Search restulsets” setting works? The description of it (see below) sounds like it will allow the above code to work, but that doesn’t seem to be the case.
I re-copied our source files on to the server and that appears to have fixed the issue I was having; I guess something had become corrupt. Interestingly, the above sample code still returns the error, but our web site is now working properly, so I guess this thread is no longer needed.
