Ok, so the point is that the query results are kept within the local scope. Got it.
I read that I could just skip the queryVar and just <cfset var queryName = ''> And even though it initially declares it as a string, once you run the query it turns it into a query structure. Thoughts? I really don't want to have to go through and queryNew() several hundred queries.... On Tue, Jun 24, 2014 at 12:56 PM, Marcus F <[email protected]> wrote: > Sorry, I was just looking at the last message. > > He's var'ing the query to make sure it's in the local scope, just as with > the variables. > > > On Tuesday, June 24, 2014 12:42:13 PM UTC-5, Jason Allen wrote: > >> I'm trying to grasp WHY i need to do that.. Ricky suggested I add the >> QueryNew line, but didn't show what to do with it/why. >> >> I'm not sure what I need to do and what the purpose is. Do I need to >> define my entire query? Is that really necessary? >> >> >> >> >> >> On Tue, Jun 24, 2014 at 12:26 PM, Marcus F <[email protected]> wrote: >> >>> Take a look at the OpenBD docs, they're often more clearn than ACF's >>> docs. >>> >>> http://openbd.org/manual/?/function/querynew >>> >>> >>> On Tuesday, June 24, 2014 12:09:26 PM UTC-5, Jason Allen wrote: >>> >>>> Hi Ricky, >>>> >>>> You mentioned that after my arguments, I should add the querynew >>>> statement. >>>> >>>> <cfset var redirectLookup = QueryNew()> >>>> >>>> I did this, and now I'm getting the following error: >>>> >>>> Expression Error; Problem occurred while parsing: var redirectLookup = >>>> QueryNew(); The function querynew requires at least 1 argument(s). >>>> >>>> I'm reading the following and I'm not grasping why I need this there, >>>> and what I can do to make it work properly. >>>> >>>> http://help.adobe.com/livedocs/coldfusion/8/htmldocs/help.html?content= >>>> functions_m-r_19.html >>>> >>>> >>>> >>>> >>>> On Thu, Jun 19, 2014 at 11:02 PM, Rawk <[email protected]> wrote: >>>> >>>>> That's really up to personal preference. My preference is to avoid >>>>> using direct "local." assignments. The only advantage I see to using the >>>>> local scope explicitly is that you can maintain the same variable name >>>>> between your arguments and local scope. However, you'd generally only >>>>> need >>>>> to do that if you want to manipulate the content of the arguments >>>>> variables >>>>> before using them while still maintaining that content in it's original >>>>> form. >>>>> >>>>> Not sure I explained that well.... Take your function, for example. >>>>> You only make use of your arguments once in the SQL. If you were to >>>>> assign >>>>> those to the local scope, the only thing you would accomplish is adding 2 >>>>> lines of code with no actual advantage. Neither the local or arguments >>>>> scopes are accessible outside of the function, so functionally, they are >>>>> both in a local scope. >>>>> >>>>> Now let's assume you want to do some basic sanitation of your >>>>> arguments before sending them to your database. Additionally, you want to >>>>> write to a log file tracking how much sanitation is being required based >>>>> on >>>>> user inputs. In this case, you might want to put your arguments in a >>>>> local >>>>> scope. For example: >>>>> >>>>> <cfset local.domain = Trim(arguments.domain)> >>>>> <cflog file="sanitationLog" message="#Len(arguments.domain) - >>>>> Len(local.domain)# character difference for #local.domain#"> >>>>> >>>>> Again, this is only necessary if you want to maintain the same >>>>> variable name between both scopes AND you want to keep track of the before >>>>> and after values of your arguments. In the above example, if you didn't >>>>> need to log the character difference, you could just manipulate the >>>>> arguments scope directly: >>>>> >>>>> <cfset arguments.domain = Trim(arguments.domain)> >>>>> >>>>> Putting this all together, if you want to maintain consistent coding >>>>> patterns, there's 2 ways to approach this: >>>>> 1. local scope all arguments and type "local." every time you want >>>>> to use a variable in a function (even for variables that were not >>>>> arguments) >>>>> 2. use different names in the local scope (using "var") when you >>>>> want to manipulate and keep track of original argument data. example: >>>>> <cfset var aDomain = Trim(arguments.domain)> >>>>> >>>>> It's my opinion that option 2 ultimately yields less code and less >>>>> code is nearly always cleaner. In most cases, I have no need to know the >>>>> original values in my arguments variables, so I just manipulate the >>>>> arguments scope directly, so it's a lot less common that I have to create >>>>> additional variables inside of a function just for my arguments. >>>>> >>>>> On a side note, speaking of input sanitation, there's something I >>>>> should have mentioned in my original reply. It's a good idea to get in >>>>> the >>>>> habit of using the cfsqltype attribute in cfqueryparam tags. This adds >>>>> another layer of protection against SQL injection because CF will throw an >>>>> error before executing any SQL if the actual data type of the value >>>>> doesn't >>>>> match the expected data type specified in in the cfsqltype attribute. As >>>>> a >>>>> bonus, this ensures proper usage of single quotes in the SQL based on the >>>>> data type. >>>>> >>>>> >>>>> On Thursday, June 19, 2014 8:23:16 PM UTC-4, Jason Allen wrote: >>>>>> >>>>>> Another question >>>>>> >>>>>> I recall reading that in a cfc you should declare a local variable >>>>>> for each argument, set the local var equal to the argument, and then >>>>>> proceed to use the local var for the rest of your operations. Is that >>>>>> true? >>>>>> >>>>>> ie: >>>>>> >>>>>> <cfset var local = structNew()> >>>>>> <cfset local.userID = "#arguments.userID#"> >>>>>> >>>>>> <cfif local.userID eq '1'>....... >>>>>> >>>>> -- >>>>> -- >>>>> online documentation: http://openbd.org/manual/ >>>>> http://groups.google.com/group/openbd?hl=en >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Open BlueDragon" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> -- >>> online documentation: http://openbd.org/manual/ >>> http://groups.google.com/group/openbd?hl=en >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Open BlueDragon" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > -- > online documentation: http://openbd.org/manual/ > http://groups.google.com/group/openbd?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Open BlueDragon" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
