hey guys,
someone was lamenting earlier either here or in a forum (i cant
remember) about the verbosity of cfqueryparam and that we didnt have
a function we could use. So for fun I whipped one up:
cffunction name=qparam access=public returntype=void output=true
cfargument name=cfsqltype
This is pretty cool. What if, however, you put the CFOUTPUT tags around
the CFQUERYPARAM tag *within* your function? Would that not eliminate
the need to put them *outside* the function?
Are you sure the #-related errors are from the function in the SQL
statement, or the #s within your function
I just want to make sure I'm using cfqueryparam properly in
conjunction with a LIKE statement inside of an SQL WHERE clause:
DC.name LIKE cfqueryparam cfsqltype=CF_SQL_VARCHAR value=%#qryString#%
It's not breaking, does that mean that I have it correct?
Thanks,
Pete
Yep, it's correct.
cheers,
barneyb
On 8/2/05, Pete Ruckelshaus [EMAIL PROTECTED] wrote:
I just want to make sure I'm using cfqueryparam properly in
conjunction with a LIKE statement inside of an SQL WHERE clause:
DC.name LIKE cfqueryparam cfsqltype=CF_SQL_VARCHAR value=%#qryString#%
It's
That will work for you - but I usually put parens around it:
LIKE (cfqueryparam cfsqltype=CF_SQL_VARCHAR value=%#qryString#%)
-mk
-Original Message-
From: Pete Ruckelshaus [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 02, 2005 3:09 PM
To: CF-Talk
Subject: SQL LIKE and CFQUERYPARAM
I
Mark A Kruger wrote:
That will work for you - but I usually put parens around it:
LIKE (cfqueryparam cfsqltype=CF_SQL_VARCHAR value=%#qryString#%)
Just out of curiousity... why?
Rick
~|
Find out how CFTicket can increase
: Tuesday, August 02, 2005 3:49 PM
To: CF-Talk
Subject: Re: SQL LIKE and CFQUERYPARAM
Mark A Kruger wrote:
That will work for you - but I usually put parens around it:
LIKE (cfqueryparam cfsqltype=CF_SQL_VARCHAR value=%#qryString#%)
Just out of curiousity... why?
Rick
, before CF 5, consistency was NOT to use CFQUERYPARAM since it
didn't exist,
and I would add another most important thing: if it aint broken, don't fix
it...
So let me reformulate my question:
Is it really worth to modify old CF applications running Access to use
CFQUERYPARAM,
and is it really
Welcome
-Original Message-
From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 4:44 PM
To: CF-Talk
Subject: RE: cfqueryparam
Mike,
The basic question is where does attributes.join come
from? If it's from a
form field (for example) a malicious user could
Hi,
Just wondering if my CFQUERYPARAM is correct... should I be also
putting cfqueryparam tags around the SET variables?
!--- update user details to DB ---
CFQUERY NAME=UpdateUserDetails
datasource=user020
UPDATE
You should use cfqueryparam *everywhere* you could specify a literal
value.
This includes SELECT, INSERT, UPDATE and DELETE statements as well as
any DDL statements that can accept literal values.
M!ke
-Original Message-
From: Saturday (Stuart Kidd) [mailto:[EMAIL PROTECTED]
Sent
Much simpler (but the same) meaning, is just that you should NEVER
have hashes inside CFQUERY tags, unless they are also inside
CFQUERYPARAM tags.
cheers,
barneyb
On 6/27/05, Dawson, Michael [EMAIL PROTECTED] wrote:
You should use cfqueryparam *everywhere* you could specify a literal
value
But then you might forget to use them when you key in some literals, such
as:
SELECT ID, BLAH FROM MYTABLE WHERE MYSTATUS = cfqueryparam value=1
cfsqltype=cf_sql_numeric /
On 6/27/05, Barney Boisvert [EMAIL PROTECTED] wrote:
Much simpler (but the same) meaning, is just that you should
There's absolutely no reason to use CFQUERYPARAM in that scenario
though, so why bother? CFQUERYPARAM does variable binding for the
database. The main purpose is to allow the statement to be cached
(kind of ;) without any dynamic pieces, and then have the dynamic
pieces inserted on the fly
You should use cfqueryparam *everywhere* you could specify
a literal value.
This includes SELECT, INSERT, UPDATE and DELETE statements
as well as any DDL statements that can accept literal values.
Column defaults and create sequence statements are the only DDL
statements I can think
Much simpler (but the same) meaning, is just that you
should NEVER have hashes inside CFQUERY tags, unless
they are also inside CFQUERYPARAM tags.
I beg to differ:
cfparam name=attributes.join default=left
cfquery name=getStuff ...
select b.*, j.columns
from basetable b
=
#GetUser.daysVisited#
WHERE userID = cfqueryparam
value='#Client.KissMyDate_UserID#'
cfsqltype=cf_sql_integer
maxlength=4
/CFQUERY
You should queryparam each of the columns being set...
Also, when I am checking a db field against another
/05, S. Isaac Dealey [EMAIL PROTECTED] wrote:
Much simpler (but the same) meaning, is just that you
should NEVER have hashes inside CFQUERY tags, unless
they are also inside CFQUERYPARAM tags.
I beg to differ:
cfparam name=attributes.join default=left
cfquery name=getStuff
Much simpler (but the same) meaning, is just that you should NEVER
have hashes inside CFQUERY tags, unless they are also inside
CFQUERYPARAM tags.
Beside the fact that use of CFQUERYPARAM may make queries more efficient,
the main advantage is to prevent SQL injection.
But what if one uses
The three most important things in software development are
consistency, consistency, and consistency. So unless there's a
compelling reason NOT to be consistent, be consistent wherever you
can. If you just get in the habit of using CFQUERYPARAM everywhere,
you'll never have to think about what
Yeah, that's true; my bad. But as you say, it's also
insecure. Far
better, and my preference, is be to do something like
this:
cfparam name=attributes.join default=left
cfquery name=getStuff ...
select b.*, j.columns
from basetable b
cfif attributes.join EQ left
are
consistency, consistency, and consistency. So unless there's a
compelling reason NOT to be consistent, be consistent wherever you
can. If you just get in the habit of using CFQUERYPARAM everywhere,
you'll never have to think about what type of database you're using.
And when you upsize from Access
Much simpler (but the same) meaning, is just that you
should NEVER
have hashes inside CFQUERY tags, unless they are also
inside
CFQUERYPARAM tags.
Beside the fact that use of CFQUERYPARAM may make queries
more efficient,
the main advantage is to prevent SQL injection.
But what if one
But what if one uses an Access database ?
One should stop!
AFAIK, SQL injection uses multiple SQL statements ...
Not necessarily. It is possible to have single statements that are
vulnerable to SQL injection attacks. And, you should see better performance
using prepared statements with Access
I agree, excpet for the one exception to this rule of sorts,
query caching. Yes, you can write your own caching mechanism,
but why? CF has one built in already, use it.
Well I don't use the CF native query caching mechanism for two
reasons. The first is that it's rather limited. The second is
The framework doesn't support maxrows in queries either for similar
reasons. Maxrows must be a number and a value of 0 produces no
results. Negatives either produce no results or an error, so rather
than simply choose an arbitrary high number like 50bil. as a default
maxrows value, I just
The framework doesn't support maxrows in queries either
for similar
reasons. Maxrows must be a number and a value of 0
produces no
results. Negatives either produce no results or an error,
so rather
than simply choose an arbitrary high number like 50bil.
as a default
maxrows value, I just
The three most important things in software development are
consistency, consistency, and consistency.
Right. However, before CF 5, consistency was NOT to use CFQUERYPARAM since it
didn't exist,
and I would add another most important thing: if it aint broken, don't fix it...
So let me
The three most important things in software
development are
consistency, consistency, and consistency.
Right. However, before CF 5, consistency was NOT to use
CFQUERYPARAM since it didn't exist,
and I would add another most important thing: if it aint
broken, don't fix it...
If it aint
quote
Is it really true that the only way for SQL injection is by using multiple
commands, and that Access DS are SQL injection free?
/quote
NOPE FALSE!
SQL injection does not require multiple commands, and Access is vulnerable!
Does that answer the first question?
--
Ian
Right. However, before CF 5, consistency was NOT to use
CFQUERYPARAM since it didn't exist, and I would add another
most important thing: if it aint broken, don't fix it...
I believe that the CFQUERYPARAM tag was introduced in CF 4.0.1, actually.
Unfortunately, for some reason I can't
cfparam name=attributes.join default=left
cfquery name=getStuff ...
select b.*, j.columns
from basetable b
#attributes.join# jointable j on (j.x = b.x)
/cfquery
I don't use this syntax because it's insecure... This is simplified to
Why is this insecure? Does it have
4.5 I think.
Adam H
On 6/27/05, Dave Watts [EMAIL PROTECTED] wrote:
Right. However, before CF 5, consistency was NOT to use
CFQUERYPARAM since it didn't exist, and I would add another
most important thing: if it aint broken, don't fix it...
I believe that the CFQUERYPARAM tag
[mailto:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 1:02 PM
To: CF-Talk
Subject: Re: cfqueryparam
I agree, excpet for the one exception to this rule of sorts,
query caching. Yes, you can write your own caching mechanism,
but why? CF has one built in already, use it.
Well I don't use the CF
from the URL and used it. Really it
all boils down to proper input validation. If you're doing it
properly, you needn't worry, but if you're not, you could be in big
trouble. CFQUERYPARAM greatly reduces the requirement, because while
it doesn't ensure the input is valid, it'll at least prevent
The built-in query caching that CF provides is quite lacking in terms
of features, and it's not very difficult to roll your own caching
component that is not only far more functional, but far more flexible.
So while it's potentially a good candiate for a bandaid while you
create a proper solution
4.5 I think.
Yes, you are correct according to the CFML History on the MM site.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf Software provides the highest caliber vendor-authorized
instruction at our training centers in Washington DC, Atlanta,
Chicago, Baltimore,
:[EMAIL PROTECTED]
Sent: Monday, June 27, 2005 3:25 PM
To: CF-Talk
Subject: Re: cfqueryparam
cfparam name=attributes.join default=left
cfquery name=getStuff ...
select b.*, j.columns
from basetable b
#attributes.join# jointable j on (j.x = b.x)
/cfquery
I don't use
While I'm a big fan of frameworks and standards, we use
Cfquery caching for lookups and static data - mostly
on legacy code that is still in production. When we do
so we scrub the variables using a UDF that removes
malicious SQL. I would hasten to add that such a UDF is
probably not 100%
thought
it meant best to use a cfqueryparam on literals within the same statement
that has the cf variables. Beyond any of that, what experience has shown me
with different developers is if it does not hurt to always do something such
as use cfqueryparam for variables or literals then people
cfparam name=attributes.join default=left
cfquery name=getStuff ...
select b.*, j.columns
from basetable b
#attributes.join# jointable j on (j.x = b.x)
/cfquery
I don't use this syntax because it's insecure... This is
simplified to
Why is this insecure? Does it have
Mike,
The basic question is where does attributes.join come
from? If it's from a
form field (for example) a malicious user could pass in:
Thanks for the thorough example Mark, well written. :)
s. isaac dealey 954.522.6080
new epoch : isn't it time for a change?
add features without
Does that answer the first question?
It does, although the vulnerability is not as high, but still...
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send any spam to this address: [EMAIL PROTECTED])
it in the dropdown
list of options when you type in cfqueryparam cfsqltype=.
Like above, you could add the CF_SQL_BLOB as well.
--
Auxilium meum a Domino
~|
Discover CFTicket - The leading ColdFusion Help Desk and Trouble
Ticket
IIRC Isaac Dealey wrote up an amazing database sniffer of
sorts that
can figure all this out by itself, but its probably
overkill here.
Still its an absolute gem that I really need to start
using myself.
Heh... thanks for the plug Matt... :)
Yea, it's probably more than you need,
Relying on the implicit conversion is lazy and error prone (since many people
accidentally
invert the condition - either while they're writing the code or, worse, when
they're reading other people's code).
Which is precisely why I stopped using the shortcut. I only type at a
mere 45 WPM,
Isaac, do you have a direct link for that article? It's probably right in
front of my face, but I didn't see it, and their search engine is down.
Its in his sig line on his post.
http://www.sys-con.com/author/?id=4806
After making the examples work on my own, it was one of the few times
I
whoops! Sys-con has rebuilt their site and disabled Search. I really
should have copied all that stuff down. Isaac, can you help?
--
--mattRobertson--
Janitor, MSB Web Systems
mysecretbase.com
~|
Logware (www.logware.us): a
Well that's interesting... the author link in my sig doesn't work
anymore -- looks like someone accidentally deleted the index.cfm in
that directory -- and when I hit the link, I get the directory
listing, even though, if I remove the query string, I get the 403
forbidden error... that can't be
Pete Ruckelshaus wrote:
OK, here's what I did, a bit more elegant than the first time. I
added the following to my UDF library include file:
snip
Um... why not:
function isNullNumeric(str) {
return not isNumeric(str);
}
function isNullString(str) {
return len(trim(str)) eq 0;
}
On 4/27/05, Al Everett [EMAIL PROTECTED] wrote:
On 4/26/05, Bryan Stevenson [EMAIL PROTECTED] wrote:
cfqueryparam value=#Trim(FORM.txtFirstName)# cfsqltype=cf_sql_varchar
null=#YesNoFormat(Len(Trim(FORM.txtFirstName))#
This is also the technique I use.
Of course I put EQ 0 at the end
On 4/26/05, Bryan Stevenson [EMAIL PROTECTED] wrote:
cfqueryparam value=#Trim(FORM.txtFirstName)# cfsqltype=cf_sql_varchar
null=#YesNoFormat(Len(Trim(FORM.txtFirstName))#
This is also the technique I use.
--
a href=http://www.spreadfirefox.com/?q=affiliatesamp;id=58370amp;t=1;Get
Firefox
arrrgg...listen to Barney (and me and Dave W)...just do it in the null
attributeno silly JS neededyou're making it WAY too complicated and
it will be a monster to maintain.
sorry for the rantit just pains me to see these kinds of solutions ;-)
Bryan Stevenson B.Comm.
VP
by looking for a value within the form field name itself. While I can
build the statement as straight SQL, I'd like to use cfqueryparam for
all the usual reasons, including the fact that it will deal with
handling those text fields properly, escaping the single quotes as
necessary.
But this doesn't seem
: cfqueryparam and null values
On 4/27/05, Al Everett [EMAIL PROTECTED] wrote:
On 4/26/05, Bryan Stevenson [EMAIL PROTECTED] wrote:
cfqueryparam value=#Trim(FORM.txtFirstName)#
cfsqltype=cf_sql_varchar
null=#YesNoFormat(Len(Trim(FORM.txtFirstName))#
This is also the technique I use
I'd say that's a slightly kludgy hack that I only mention because the
'right' solution was proposed and overruled. You're implicitly
coercing the numeric result returned by 'len' into a boolean value,
which works, because of the typeless nature of CF. By using a numeric
comparison that returns
I'd say that's a slightly kludgy hack that I only mention
because the 'right' solution was proposed and overruled.
You're implicitly coercing the numeric result returned by
'len' into a boolean value, which works, because of the
typeless nature of CF. By using a numeric comparison that
bah! ;-)
yes I do occasionally get the good old cannot convert to boolean but those
are sorted before going to prod ;-)
I've been doing it since '98...little set in my ways...but I hear ya..
Bryan Stevenson B.Comm.
VP Director of E-Commerce Development
Electric Edge Systems Group Inc.
phone:
NOT len(somevalue) is just as clear.
Russ
-Original Message-
From: Barney Boisvert [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 27, 2005 11:36 AM
To: CF-Talk
Subject: Re: cfqueryparam and null values
I'd say that's a slightly kludgy hack that I only mention because the
'right
I'd say that's a slightly kludgy hack that I only mention
because the 'right' solution was proposed and overruled.
You're implicitly coercing the numeric result returned by
'len' into a boolean value, which works, because of the
typeless nature of CF. By using a numeric comparison that
is marginal at best. But at this point, we might as well be arguing about
how many angels can dance on the head of a pin.
5..I counted...
Bryan Stevenson B.Comm.
VP Director of E-Commerce Development
Electric Edge Systems Group Inc.
phone: 250.480.0642
fax: 250.480.1264
cell: 250.920.8830
Who suggested a method using JS?
On 4/27/05, Bryan Stevenson [EMAIL PROTECTED] wrote:
arrrgg...listen to Barney (and me and Dave W)...just do it in the null
attributeno silly JS neededyou're making it WAY too complicated
and
it will be a monster to maintain.
sorry for the
by looking for a value within the form field name itself. While I can
build the statement as straight SQL, I'd like to use cfqueryparam for
all the usual reasons, including the fact that it will deal with
handling those text fields properly, escaping the single quotes as
necessary
All the posts not from Barney/Dave/myselfnot sure who specifically...I
just saw the solution heading off in the wrong direction IMHO
and perhaps it was CFSCRIPT and not JS (just remembering the mention of a
UDF now)
Bryan Stevenson B.Comm.
VP Director of E-Commerce Development
heh ... it was probably CFSCRIPT, was curious how in the world JS could be
used for this, now THAT would be over-complicated I am sure.
On 4/27/05, Bryan Stevenson [EMAIL PROTECTED] wrote:
All the posts not from Barney/Dave/myselfnot sure who specifically...I
just saw the solution
Bryan Stevenson wrote:
arrrgg...listen to Barney (and me and Dave W)...just do it in the null
attributeno silly JS neededyou're making it WAY too complicated and
it will be a monster to maintain.
sorry for the rantit just pains me to see these kinds of solutions ;-)
Oh,
You should have no problem with this. I wrote a free tool called
GridMonger that has SQL inserts and updates that run completely
conditionally. They take a list of parameters and use those to decide
how to build the SQL. What you're describing sounds simpler than
that, but you can look at code
In Java, numbers are not boolean values, and if you try to use one as
such you'll get a compiler error.
I'm not saying that NOT len(string) is a no-no, just that I think
len(string) EQ 0 is clearer and easier to understand. It's all
personal preference. If Sean's guidelines recommend the
On 4/27/05, COLLIE David [EMAIL PROTECTED] wrote:
Whilst I agree with you about implicitly coercing the numeric result,
I'm sure I've heard Mr Cofield (or rathter certain guidelines) advocate
that very method in coding guidelines... Are the ones I got out of date
of have I got my memories
Hi,
I need to build a SQL update statement dynamically,
based on what form fields are being passed in at a
particular time. The database is MS SQL Server.
snip
But this doesn't seem possible, since I have to
output the SQL string in the cfquery statement.
I can build the cfqueryparam
IIRC Isaac Dealey wrote up an amazing database sniffer of
sorts that
can figure all this out by itself, but its probably
overkill here.
Still its an absolute gem that I really need to start
using myself.
Heh... thanks for the plug Matt... :)
Yea, it's probably more than you need, but
On 4/27/05, Sean Corfield [EMAIL PROTECTED] wrote:
On 4/27/05, COLLIE David [EMAIL PROTECTED] wrote:
Whilst I agree with you about implicitly coercing the numeric result,
I'm sure I've heard Mr Cofield (or rathter certain guidelines) advocate
that very method in coding guidelines... Are
Whilst I agree with you about implicitly coercing the
numeric result,
I'm sure I've heard Mr Cofield (or rathter certain guidelines)
advocate that very method in coding guidelines... Are the
ones I got
out of date of have I got my memories completely mixed up?
You're mixed up -
Thanks to all, especially to Isaac for his very specific example. I'm
not sure why I felt it necessary to build the SQL statement outside
the cfquery. -- perhaps because I've seen others demonstrate
handling dynamic SQL in that manner. But of course, simply putting all
the logic within the cfquery
I have a requirement to store long URLs in my database (VARCHAR (256)). Of
course this URL is often a parameter in my queries. How can I prevent a SQL
injection attack using cfqueryparam? Checking for max length is not going to
help because there could easily be a nasty SQL statement far shorter
CFQUERYPARAM prevents injection just by virtue of using the tag,
there's nothing else you need to do.
cheers,
barneyb
On 4/27/05, Clark Slater [EMAIL PROTECTED] wrote:
I have a requirement to store long URLs in my database (VARCHAR (256)). Of
course this URL is often a parameter in my queries
I have a requirement to store long URLs in my database
(VARCHAR (256)). Of course this URL is often a parameter in
my queries. How can I prevent a SQL injection attack using
cfqueryparam? Checking for max length is not going to help
because there could easily be a nasty SQL statement far
Are there any best practices for nulling cfqueryparam values?
Currently I'm having to write a cfscript before this insert query that
checks each value and then sets a specific null variable value that is
then called from the cfqueryparam tag, otherwise the query fails.
Problem is, it's a ton
cfqueryparam value=dog cfsqltype=cf_sql_varchar null=#dog EQ cat#
/
--
Damien McKenna - Web Developer - [EMAIL PROTECTED]
The Limu Company - http://www.thelimucompany.com/ - 407-804-1014
#include stdjoke.h
~|
Discover CFTicket
there is a null attribute for cfqueryparam that takes a yes/no value. even
if you have a value specified, if 'null' is set to yes, a null value gets
inserted.
On 4/26/05, Pete Ruckelshaus [EMAIL PROTECTED] wrote:
Are there any best practices for nulling cfqueryparam values?
Currently I'm
I didn't quite understand your email, but there is an attribute
null=yes|no for cfqueryparam. Is that of any use to you?
Ade
-Original Message-
From: Pete Ruckelshaus [mailto:[EMAIL PROTECTED]
Sent: 26 April 2005 22:02
To: CF-Talk
Subject: cfqueryparam and null values
Are there any
cfqueryparam value=#Trim(FORM.txtFirstName)# cfsqltype=cf_sql_varchar
null=#YesNoFormat(Len(Trim(FORM.txtFirstName))#
HTH
Cheers
Bryan Stevenson B.Comm.
VP Director of E-Commerce Development
Electric Edge Systems Group Inc.
phone: 250.480.0642
fax: 250.480.1264
cell: 250.920.8830
e-mail
How does this treat you?
cfqueryparam cfsqltype=cf_sql_integer value=#myVariable#
null=#NOT isNumeric(myVariable)# /
cheers,
barneyb
On 4/26/05, Pete Ruckelshaus [EMAIL PROTECTED] wrote:
Are there any best practices for nulling cfqueryparam values?
Currently I'm having to write a cfscript
Here's what I'm doing:
QUERY
cfscript
if (isNumeric(getDataCards.dcardid)) {
dcardid_null=no;
} else {
dcardid_null=yes;
}
/cfscript
And in the insert statement:
cfqueryparam value=#getRecordData.dcardid#
cfsqltype=CF_SQL_INTEGER null
cfqueryparam value=#Trim(FORM.txtFirstName)#
cfsqltype=cf_sql_varchar
null=#YesNoFormat(Len(Trim(FORM.txtFirstName))#
You just made the same mistake I often make. If the user entered a value,
that's when you don't want to use NULL:
NULL=#YesNoFormat(not Len(Trim(Form.txtFirstName))#
Dave
errrp...thanks Dave...yep...shoulda checked before the evil Send ;-)
Bryan Stevenson B.Comm.
VP Director of E-Commerce Development
Electric Edge Systems Group Inc.
phone: 250.480.0642
fax: 250.480.1264
cell: 250.920.8830
e-mail: [EMAIL PROTECTED]
web: www.electricedgesystems.com
=no;
} else {
dcardid_null=yes;
}
/cfscript
And in the insert statement:
cfqueryparam value=#getRecordData.dcardid#
cfsqltype=CF_SQL_INTEGER null=#dcardid_null#
So, yeah, I'm using the null attribute, I just don't want to go
through the shenanigans to determine the value for that attribute
I always forget that comparison operators generate a result
Hence things are possible like:
cfreturn myVar EQ 9 /
or null=#myVar EQ 10# in cfqueryparam tags (null takes a
string-literal representation of a boolean, hence that resolves to
null=true or null=false).
They generate a result
{
response = yes;
}
return response;
}
And my cfqueryparam, when called, looks like this:
cfqueryparam value=#getRecordData.categoryid#
cfsqltype=CF_SQL_INTEGER
null=#isNullNumeric(getRecordData.categoryid)#
Easier and reusable :)
Pete
directly in the 'null'
attribute's value.:
cfqueryparam value=#getRecordData.categoryid#
cfsqltype=CF_SQL_INTEGER
null=#NOT isNumeric(getRecordData.categoryid)#
No extraneous UDFs, no extraneous conditionals, and much easier to
read, because 'isNumeric' clearly communicates what it's doing
(checking
Does anyone know if it is possible to use cfqueryparam to bind a string to an
MS SQL full-text search column?
Here's what I'm trying:
cfquery name=VARIABLES.qrySomeQuery datasource=#REQUEST.DataSource#
SELECT *
FROMSomeTable
WHERE CONTAINS(SomeColumn_varchar, 'FORMSOF
Generally speaking a cfqueryparam value should never be surrounded by
quotes -- the functionality of separating the content from the sql
syntax is provided by the bind parameter, so if the server needs
quotes to create the bind variable they're used somewhere else
(outside the sql syntax)... You
James Reily wrote:
cfquery name=VARIABLES.qrySomeQuery datasource=#REQUEST.DataSource#
SELECT *
FROMSomeTable
WHERE CONTAINS(SomeColumn_varchar, 'FORMSOF (INFLECTIONAL,
cfqueryparam cfsqltype=cf_sql_varchar value=#VARIABLES.SomeString# )')
/cfquery
I get back
Removing the quotes worked!
Thanks guys!
-James
~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message:
That's what I thought but thanks for the extra info and link guys! Thanks again,
Phil
S. Isaac Dealey wrote:
cfqueryparam handles it for you...
provided you turn on the unicode option for that DSN. blogged about in
boring detail:
http://www.sustainablegis.com/blog/cfg11n/index.
cfm
Ok, I've been pulling my hair out for two straight days now on this. I have a
numeric field that I am populating with the results of a previous query. The
column in this query could return a null value. If I set the CFQUERYPARAM null
option to Yes it doesn't throw an error but everything
Ok, I've been pulling my hair out for two straight days now
on this. I have a numeric field that I am populating with the
results of a previous query. The column in this query could
return a null value. If I set the CFQUERYPARAM null option to
Yes it doesn't throw an error but everything
I don't think the NULL option is to allow NULLsit's to pass NULLs...so
it's acting as it should (keep in mind I've never tested this).
I usually do this:
cfif Len(Trim(MyDataVar))
cfqueryparam...
cfelse
NULL
/cfif
and if there is a shorter way...someone please educate me
cfqueryparam ... null=#some expression that returns yes if you want the
value to be NULL, or no otherwise#
So Davewhat you've said looks like it will pass a NULL if the expression
evaluates to YES and will pass the correct value if the expression evaluates
to NO??
TIA
Bryan Stevenson
the CFQUERYPARAM
null option to Yes it doesn't throw an error but everything is passed as a
null. Am I missing something here? Maybe I've been looking at it too long.
Thanks for any help,
If you specify Yes, then CF will ignore any value in the value
attribute. If it's conditional, simply do
801 - 900 of 1538 matches
Mail list logo
