Hey Nathan, This was with cfstoredproc and cfprocparam, with this I have seen no lapse or delay in SP's. My point was merely that it was wrong of a DBA to assume and state that the use of SP's was wrong.
>>That's not the point at all. We all know stored procedures are faster than plain vanilla sql statements. That's not in question, it's common sense. Not true in all cases, we have had cases where an SP coded in SQL with complex concepts is way slower than a SELECT and then all the logic performed in CF - it's annoying when you have to do that but since CF does not adhere to the timeout concept in CF sometimes it has to be done! I still don't see any performance lag and we run SQL Profiler constantly! Sure it is creating and using internal SP's but they are literally mini footprints - certainly smaller footprints (in time) that it would be for CF to startup, parse, shutdown and perform SQL passing... No big deal, just what we have noticed and what we measure - its been a good thread so far ;-) -----Original Message----- From: Nathan Strutz [mailto:[EMAIL PROTECTED] Sent: 22 December 2004 16:59 To: CF-Talk Subject: Re: CFStoredProc bug? Robertson-Ravo, Neil (RX) wrote: > Based on the comments - I ran a quick test with an SP which basically ran > the following (where iLanguageID and iEventID were @ variables passed in via > dbvarname): How did you call the procedure, with cfquery or with cfstoredproc? Did you use <cfqueryparam>'s? That's actually what this part of the thread is about. I suggest you try ALL the possibilities. > > Now, this is by no means a solid call as it can fluctuate between them both > taking 0 duration but never the SP taking any more than that and shows its > more efficient. > That's not the point at all. We all know stored procedures are faster than plain vanilla sql statements. That's not in question, it's common sense. > Client vars do perform updates internally using SP's for EVERY CALL if you > do not switch that method off via the Client Vars section - maybe this is > what your DBA was seeing? This does indeed cause 3 SP's to run for every > .CFM thread; turn the updates off if you don't need last visit and hit count > updated constantly. Yes, I know that, problem is the app was relying on these variables. After disabling these updates, there was still overhead and inefficency on the DB storage for client vars. Run SQL Profiler on your database and you'll see it compiling and removing procedures all the time, not very good practice. -nathan strutz http://www.dopefly.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - New Atlanta http://www.newatlanta.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188608 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
