I should add to this that the queries are not using any caching, they are not in a cfc, and are not loaded into any scopes like the application. Simple, inline, straightforward queries.
On 3/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Scott - thats precisely why we use cfqueryparam - and the performance > increase is marked, especially on inserts. There is a performance hit > on the first time the query is put together, but after that you save > time. > > Andrew - I thought the cached templates could be it - but its not, we > just ran a control test: turn off cache, restart cf, change column, > try query. And it still errors. > > On Mar 2, 1:33 pm, Andrew Scott <[EMAIL PROTECTED]> wrote: > > Scott, > > > > Well although I know what you said, I see no reason to add overhead to my > > application to provide a stop measure for SQL injection when I have already > > taken care of it before my code ever reaches there in a cffunction. As far > > as making sure it is an integer instead of numeric, I couldn't care less > > it's not an overhead I will put into my applications. > > > > And to be honest, I would prefer to write SP's and have it on the DB side if > > that to be the case. > > > > Andrew Scott > > Senior Coldfusion Developer > > Aegeon Pty. Ltd.www.aegeon.com.au > > Phone: +613 8676 4223 > > Mobile: 0404 998 273 > > > > -----Original Message----- > > From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf > > > > Of Scott Thornton > > Sent: Friday, 2 March 2007 12:25 PM > > To: cfaussie@googlegroups.com > > Subject: [cfaussie] @#$!! queryparam > > > > Andrew, > > > > I disagree. > > > > Although cfqueryparam performs vailidation, it is not the reason you should > > be using it. > > > > cfqueryparam makes the database engine use parameter binding on your > > queries. For example your query below would look different to the db engine > > every time it is run > > > > eg: > > Select * from Employees where EmployeeId = 1 > > Select * from Employees where EmployeeId = 2 > > Select * from Employees where EmployeeId = 3 > > > > so your database engine builds different query execution plans for each of > > these queries (in addition to validating the query, checking\casting the > > parameter types etc) > > > > etc > > > > But with parameter binding the databse engine is executing something that > > looks more like a stored procedure, > > > > Select * from Employees where EmployeeId = @var1 > > > > Here is an example from a SQL profile trace on my server: > > > > declare @P1 int > > set @P1=30 > > exec sp_prepexec @P1 output, N'@P1 decimal(38,0)', N'SELECT > > IsNull(COUNT(ITEM.SB_INVOICE_ITEM_ID),0) AS CNT, > > IsNull(SUM(ITEM.SB_INVOICE_COST),0) AS TOT_COST, > > IsNull(SUM(CASE WHEN ITEM.SB_ITEM_STATUS_CODE = > > ''ER'' THEN 1 ELSE 0 END),0) AS ERR_COUNT > > FROM > > SB_INVOICE_ITEM ITEM > > WHERE > > ITEM.SB_INV_BATCH_ID = @P1 ', 1387 > > select @P1 > > > > > -- Duncan I Loxton [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
