whats wrong with using cfqueryparam ? I did read earlier you want this to work the DWMX and server behaviours. I remember seeing a talk at MXDU where you can extend/change the way dreamweaver works when it inserts code. Im sure you could change your DWMX setup so that it puts cfqueryparam tags around any strings rather than just inserting them into the SQL.
This is should also prevent your code from SQL injection attacks and at the same time give you a performance increase if you happen to use the same query more than once. Pat "Beattie, Barry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > >> 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/
