>> In which case, prove me wrong!
I can't. ASP doesn't work like CF.
>> To store the string "{ts it ain't 'alf 'ot, mum}" in a text field without
using cfqueryparam, you can double up your single quotes
this was mandetory in ASP but it isn't in CF since CF is smart enough to
leave single quotes alone in CFQUERY.
so that's why I can get away with this.
<%
myTestString = "{ts '10101010101'}"
sql = "insert into tTest1(valTest1) " _
& "values('" & replace(myTestString, "'", "''") & "');"
conn.execute(sql)
%>
but if I do this
<cfset myTestString = "{ts it ain't 'alf 'ot, mum}">
<cfquery name="qTestInsertText" datasource="scratch">
insert into tTest1(valTest1)
values('#replace(myTestString, "'", "''", "all")#')
</cfquery>
it doubles the quotes inserted into the db.
of the years I've been programming in ASP I never had this problem, nor
needed to worry about it. A string is a string is a string. End of story.
Are you saying that the only reliable way I can insert a string is to either
check for the "{ts" or use a queryparam? any other way is unreliable?
unbelieveable!
bring on the flames
barry.b
-----Original Message-----
From: Ben Bishop [mailto:[EMAIL PROTECTED]
Sent: Thursday, 9 October 2003 2:34 PM
To: CFAussie Mailing List
Subject: [cfaussie] Re: I think this is a CFMX bug. Please prove me wr -
ong.
Hi Barry,
To store the string "{ts it ain't 'alf 'ot, mum}" in a text field
without using cfqueryparam, you can double up your single quotes
(escapes them) like:
<cfset myTestString = "{ts it ain''t ''alf ''ot, mum}">
Though just like escaping hashes in CF (eg: <cfoutput>Doggy
##4</cfoutput>), this isn't a CF requirement but a SQL one.
>> If anything its going to be the behaviour of the ODBC/JDBC driver
that is
>> causing the problem.
>
> fair enough but since the drivers ship with CF, who's problem is it?
It's yours. Try running your SQL statement in Access (or SQL Server for
that matter). It would spit back the same error - "Syntax error (missing
operator)".
Same would happen if you sent "{d 'value'}", "{t 'value'}", "{guid
'nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn'}", etc.
>> It would appear that the {ts prefix is reserved for ODBC style date/time
>> values.
>
> then it's an "undocumented feature". I couldn't find any info
specifically
> on this. Certainly this is news to people on this list. I must be the
only
Have you searched for "ODBC escape sequences" or "timestamp escape
sequences"?
ODBC escape sequences are recognized and parsed by drivers, and are well
documented.
>>>It seems reasonable that the driver should be able to make the
assumption
>
>I dissagree strongly! Assumptions are dangerous.
Like assuming a CF bug when this is known part of the SQL CAE spec for
sending language extensions recognized and parsed by drivers.
>One area of CF that I fine annoying is inconsistancies. I'm having to
>constantly refer to docs instead of educated guesses because of this. I'll
>accept that in each case there are explainations for each one but what you
>end up with are far too many exceptions to the rules. This {ts} issue is a
>case in point.
Nothing to do with CF. While I'm not doubting your frustration, your
beef here is with SQL, not CF.
>Sure CFQUERYPARAM will get around it but I still reckon it shouldn't
happen.
>Even Microsoft admits to things like this as bugs (eventually...).
So you would rather MS ignore the 1992 SQL CAE specification for
processing exceptions and additions to the standard SQL language? Please
don't encourage them :)
Of course, I may be entirely wrong. In which case, prove me wrong!
cheers,
Ben
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
