RE: The Value of CFQUERYPARAM
> I haven't heard anyone mention the security value of cfqueryparam... > using this tag will prevent someone from injecting malicious code into > your queries. The current discussion of CFQUERYPARAM concerned whether to use it for literal values, rather than values derived from variables. In that case, there's no security issue, since there's no user or program input. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Well, the main reason we weren't discussing the security value of cfqueryparam is that we were talking about constant values that were NOT collected from a user, but rather hard coded into the query. Now user interaction usually means no opportunity for user mischief. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA -Original Message- From: Gaulin, Mark [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 6:13 AM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM I haven't heard anyone mention the security value of cfqueryparam... using this tag will prevent someone from injecting malicious code into your queries. Consider this example: select id, username from people where userid = #url.userid# If someone calls this page with the url "sample.cfm?userid=1+go+delete+*+from+people" there is a chance that the people table will get nuked. cfqueryparam prevents this from happening. Mark -Original Message- From: Jochem van Dieten [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:54 PM To: CF-Talk Subject: Re: The Value of CFQUERYPARAM [EMAIL PROTECTED] wrote: > > I asked this question and quite a discussion broke out between the DB > heavyweights (Jochem and Adam I think) Thank you :-) > I've tried my best to find it in the archives but I can't for some > reason. http://www.houseoffusion.com/cf_lists/index.cfm?method=messages 110&forumid=4#121513> &threadid=24110&forumid=4#121513 I hope I am doing Adam's position justice when I summarise the debate as follows: - with cfqueryparam, changes in the value of a parameter will not lead to a recompilation (overhead) of the query execution plan in the DBMS - this is genarally a good thing, because it means a query like select * from table where id = X gets only compiled once, regardless of the value of X - therefore, if you use cfqueryparam for constants as well, the query will still be only compiled once (Adam) - but if you don't use cfqueryparam, you can force a recompilation of the query execution plan if you want so (Jochem) I am still not sure we actually disagree :-) Jochem -- When you don't want to be surprised by the revolution organize one yourself - Loesje _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
I haven't heard anyone mention the security value of cfqueryparam... using this tag will prevent someone from injecting malicious code into your queries. Consider this example: select id, username from people where userid = #url.userid# If someone calls this page with the url "sample.cfm?userid=1+go+delete+*+from+people" there is a chance that the people table will get nuked. cfqueryparam prevents this from happening. Mark -Original Message- From: Jochem van Dieten [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:54 PM To: CF-Talk Subject: Re: The Value of CFQUERYPARAM [EMAIL PROTECTED] wrote: > > I asked this question and quite a discussion broke out between the DB > heavyweights (Jochem and Adam I think) Thank you :-) > I've tried my best to find it in the archives but I can't for some > reason. http://www.houseoffusion.com/cf_lists/index.cfm?method=messages 110&forumid=4#121513> &threadid=24110&forumid=4#121513 I hope I am doing Adam's position justice when I summarise the debate as follows: - with cfqueryparam, changes in the value of a parameter will not lead to a recompilation (overhead) of the query execution plan in the DBMS - this is genarally a good thing, because it means a query like select * from table where id = X gets only compiled once, regardless of the value of X - therefore, if you use cfqueryparam for constants as well, the query will still be only compiled once (Adam) - but if you don't use cfqueryparam, you can force a recompilation of the query execution plan if you want so (Jochem) I am still not sure we actually disagree :-) Jochem -- When you don't want to be surprised by the revolution organize one yourself - Loesje _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: The Value of CFQUERYPARAM
[EMAIL PROTECTED] wrote: > > I asked this question and quite a discussion broke out between the DB > heavyweights (Jochem and Adam I think) Thank you :-) > I've tried my best to find it in the archives but I can't for some > reason. http://www.houseoffusion.com/cf_lists/index.cfm?method=messages&threadid=24110&forumid=4#121513 I hope I am doing Adam's position justice when I summarise the debate as follows: - with cfqueryparam, changes in the value of a parameter will not lead to a recompilation (overhead) of the query execution plan in the DBMS - this is genarally a good thing, because it means a query like select * from table where id = X gets only compiled once, regardless of the value of X - therefore, if you use cfqueryparam for constants as well, the query will still be only compiled once (Adam) - but if you don't use cfqueryparam, you can force a recompilation of the query execution plan if you want so (Jochem) I am still not sure we actually disagree :-) Jochem -- When you don't want to be surprised by the revolution organize one yourself - Loesje [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Oracle does a hash on the statement and if it does not have a match in memory then it will "recompile" the statement. Any change including whitespace or change of case can cause a "recompile." The use of bind variables can prevent a "recompile." If you choose not to use bind variables on a statement that is used often and you run into database performance problems expect a call from your DBA Kore Peterson Shawn McKee <[EMAIL PROTECTED] To: CF-Talk <[EMAIL PROTECTED]> nd.com> cc: Subject: RE: The Value of CFQUERYPARAM 12/08/2003 01:28 PM Please respond to cf-talk I just talked to my Oracle DBA and if the query is all constants SELECT M FROM S WHERE W = 'huh' it will get parsed once and put in the cache. SELECT M FROM S WHERE W = '#url.k#' Gets parsed every time the contents of url.k changes SELECT M FROM S WHERE W = ? ? = 'huh' Is the solution for this because the QUERYPARAM is a bind variable that the DB can handle and knows no to parse again. Shawn McKee -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 12:58 PM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM As far as I know, yes, it does recompile every time. And it is quite intuitive, just look at the debug of what is sent to the DB server for something like: SELECT M FROM S WHERE W = '#url.k#' and SELECT M FROM S WHERE W = 'huh' Assuming url.k is 'huh' you get the same thing sent to the DB server. However, if you use cfqueryparam what is sent: SELECT M FROM S WHERE W = ? ? = 'huh' So the DB compiles (only once) the query and puts in 'huh' as the argument. Summarizing it doesn't matter whatever 'huh' is static or from a variable, it is still treated the same way. Also, it would help to remember that #your_var_here# causes the value of the var to be printed and it becomes static text. TK -----Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:47 PM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Even though the value is static and unchanging, the query will be recompiled every time? This seems to be a bit counter intuitive to me, but it is basically what I'm trying to confirm. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA -----Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 10:43 AM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Use CFQUERYPARAM as the DB engine will only compile you query once and hopefully cache it. Otherwise it will re-compile every time. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:36 PM To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in ...> tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any
RE: The Value of CFQUERYPARAM
If you've got both, it doesn't really matter, though the former is probably a hair faster, and it's certainly easier to read. > -Original Message- > From: Ian Skinner [mailto:[EMAIL PROTECTED] > Sent: Monday, December 08, 2003 11:54 AM > To: CF-Talk > Subject: RE: The Value of CFQUERYPARAM > > Just for fun then if you have a mix of constants and > variables would it be > written like this? > > SELECT * > FROM table > WHERE status = 'A' > AND ID = > > or > > SELECT * > FROM table > WHERE status = > AND ID = > > or > > WHERE STATUS = 'M' > > Is there any real advantage of one of these forms over the other? > > Just to repeat, these are hard coded, unchanging values > NOT passed in > with > variables or constants. I understand the value of the > > tags > in conjunction with passing in data with variables, > especially data from > user forms. > > -- > Ian Skinner > Web Programmer > BloodSource > www.BloodSource.org > Sacramento, CA > > Confidentiality Notice: This message including any > attachments is for the sole use of the intended > recipient(s) and may contain confidential and privileged > information. Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the > intended recipient, please contact the sender and > delete any copies of this message. > _ > _ > _ > > > [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
> The second answer still uses the CFQUERYPARAM bonuses for
> queries, so if you use the same SQL somewhere else, just
> changing the one field, then use CFQUEYPARAM...
>
> Disadvantage of using CFQUERYPARAM? You can't cache them!
You can't use cachedwithin/cachedafter. You can certainly cache it manually.
if(not isdefined("application.foo")) {
do the query and store in app scope
}
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
RE: The Value of CFQUERYPARAM
That made little sense. I meant to write:L SELECT * FROM table WHERE status = 'A' AND ID = or SELECT * FROM table WHERE status = AND ID = That should be a better example. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA -Original Message- From: Ian Skinner Sent: Monday, December 08, 2003 11:54 AM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Just for fun then if you have a mix of constants and variables would it be written like this? SELECT * FROM table WHERE status = 'A' AND ID = or SELECT * FROM table WHERE status = AND ID = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. _ _ _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Both will work, both will be cached. IMHO it is easier to read the query if the constants are not bind variables. Shawn McKee -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:54 PM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Just for fun then if you have a mix of constants and variables would it be written like this? SELECT * FROM table WHERE status = 'A' AND ID = or SELECT * FROM table WHERE status = AND ID = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. _ _ _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
> I would think the former from the answers in this forum, but > I'm not sure. Or are they both the same really, and it doesn't matter? The second answer still uses the CFQUERYPARAM bonuses for queries, so if you use the same SQL somewhere else, just changing the one field, then use CFQUEYPARAM... Disadvantage of using CFQUERYPARAM? You can't cache them! [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Just for fun then if you have a mix of constants and variables would it be written like this? SELECT * FROM table WHERE status = 'A' AND ID = or SELECT * FROM table WHERE status = AND ID = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. _ _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
I just talked to my Oracle DBA and if the query is all constants SELECT M FROM S WHERE W = 'huh' it will get parsed once and put in the cache. SELECT M FROM S WHERE W = '#url.k#' Gets parsed every time the contents of url.k changes SELECT M FROM S WHERE W = ? ? = 'huh' Is the solution for this because the QUERYPARAM is a bind variable that the DB can handle and knows no to parse again. Shawn McKee -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 12:58 PM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM As far as I know, yes, it does recompile every time. And it is quite intuitive, just look at the debug of what is sent to the DB server for something like: SELECT M FROM S WHERE W = '#url.k#' and SELECT M FROM S WHERE W = 'huh' Assuming url.k is 'huh' you get the same thing sent to the DB server. However, if you use cfqueryparam what is sent: SELECT M FROM S WHERE W = ? ? = 'huh' So the DB compiles (only once) the query and puts in 'huh' as the argument. Summarizing it doesn't matter whatever 'huh' is static or from a variable, it is still treated the same way. Also, it would help to remember that #your_var_here# causes the value of the var to be printed and it becomes static text. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:47 PM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Even though the value is static and unchanging, the query will be recompiled every time? This seems to be a bit counter intuitive to me, but it is basically what I'm trying to confirm. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 10:43 AM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Use CFQUERYPARAM as the DB engine will only compile you query once and hopefully cache it. Otherwise it will re-compile every time. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:36 PM To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in ...> tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. _ _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
> Another consideration is that you cannot use CF query caching on > a query that uses CFQUERYPARAM tags. (At least with CF5 and earlier.) I'm pretty sure this is also true with CFMX. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
>> Even though the value is static and unchanging, the query will be recompiled every time? This seems to be a bit counter intuitive to me, but it is basically what I'm trying to confirm. In the most ineloquent and non-technical way (and with respect to Oracle who supports the bind vars) If you use the cfqueryparam round the static var... then it will treat that bit of SQL as dynamic and will recompile every time If you don't put it in a cfqueryparam then it will tell the dbengine that that bit of SQL is not going to change... dont bother trying to treat it dynamically resources freed I asked this question and quite a discussion broke out between the DB heavyweights (Jochem and Adam I think) I've tried my best to find it in the archives but I can't for some reason. The rule I got from listening to others was to *only* use cfqueryparam for dynamic vars in the SQL (dates are an exception cos there a PITA anyway) if they aint gonnae change, why put them in cfqueryparam? http://www.macromedia.com/devnet/server_archive/articles/cfqueryparam_or acle_databases.html#4 CFQUERYPARAM In the example query, ColdFusion Server will send the query to the Oracle database as: SELECT username FROM users WHERE user_id=:1 The ":1" is a substitution variable (parameter reference). The execution path is the same whether the userID is 2236 or 39393. Because there's no use in parsing it more than once, ColdFusion can use the cached query in the cache and thus conserve server resources. ie what's the point in forcing this parse if it is not necessary it's the DBEngine that caches the query... not CF -- -dc [ cf5, ora8.1.7, iis5 ] [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
As far as I know, yes, it does recompile every time. And it is quite intuitive, just look at the debug of what is sent to the DB server for something like: SELECT M FROM S WHERE W = '#url.k#' and SELECT M FROM S WHERE W = 'huh' Assuming url.k is 'huh' you get the same thing sent to the DB server. However, if you use cfqueryparam what is sent: SELECT M FROM S WHERE W = ? ? = 'huh' So the DB compiles (only once) the query and puts in 'huh' as the argument. Summarizing it doesn't matter whatever 'huh' is static or from a variable, it is still treated the same way. Also, it would help to remember that #your_var_here# causes the value of the var to be printed and it becomes static text. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:47 PM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Even though the value is static and unchanging, the query will be recompiled every time? This seems to be a bit counter intuitive to me, but it is basically what I'm trying to confirm. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 10:43 AM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Use CFQUERYPARAM as the DB engine will only compile you query once and hopefully cache it. Otherwise it will re-compile every time. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:36 PM To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in ...> tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Another consideration is that you cannot use CF query caching on a query that uses CFQUERYPARAM tags. (At least with CF5 and earlier.) Chris -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:36 PM To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Even though the value is static and unchanging, the query will be recompiled every time? This seems to be a bit counter intuitive to me, but it is basically what I'm trying to confirm. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 10:43 AM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Use CFQUERYPARAM as the DB engine will only compile you query once and hopefully cache it. Otherwise it will re-compile every time. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:36 PM To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Doesn't it only recompile when the values change and queryparam gets around that? I think if the values are constant there is no advantage to putting them in a param, but that depends on if it recompiles every time or not. Shawn McKee -Original Message- From: Tom Kitta [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 12:43 PM To: CF-Talk Subject: RE: The Value of CFQUERYPARAM Use CFQUERYPARAM as the DB engine will only compile you query once and hopefully cache it. Otherwise it will re-compile every time. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:36 PM To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Hard code them Jochem's words of wisdom... Oracle uses cfqueryparam to bind vars If you don't, the DB Query Engine (or summat) will treat them as dynamic bind variables and although it probably doesn't harm that much to have them in cfqueryparam, they aren't bind vars... they are constants thus don't need it ... trying to find the link to it in the archives at the moment to the discussion -- dc -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: 08 December 2003 18:36 To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: The Value of CFQUERYPARAM
Use CFQUERYPARAM as the DB engine will only compile you query once and hopefully cache it. Otherwise it will re-compile every time. TK -Original Message- From: Ian Skinner [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2003 1:36 PM To: CF-Talk Subject: The Value of CFQUERYPARAM When writing a select statement, if I have a part of a WHERE clause that will be static, always the same value, and this value is not passed in with a variable or constant, is there any inherent value in tags? An Example: WHERE STATUS = or WHERE STATUS = 'M' Is there any real advantage of one of these forms over the other? Just to repeat, these are hard coded, unchanging values NOT passed in with variables or constants. I understand the value of the tags in conjunction with passing in data with variables, especially data from user forms. -- Ian Skinner Web Programmer BloodSource www.BloodSource.org Sacramento, CA Confidentiality Notice: This message including any attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender and delete any copies of this message. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
