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/
