Francisco Tapia
fhtapia at gmail.com
Thu Sep 23 21:34:41 CDT 2010
Really? YES JOHN, everyone here knows you've been here for 15 yrs... hey wait... where the computers that far back? ;-) weren't they called typewriters? still... you missed the point of the article in that just because you avoid using the "term" cursor it does not solve the issue of avoiding cursors. additionally didn't I also state that there will be times when a cursor "might" be justified... sure you "COULD" google for examples but what would be the fun of that? http://www.sql-server-performance.com/tips/cursors_p1.aspx additonally...nobody here claims to be gods... maybe your time on here makes you think you are one but ... nope you're not... i might have been struck by lightning for mentiong the bound forms comment early on in the thread. I won't rant at anyone else because it's the poor guy's blog... I liked the point he was trying to make, just because you are writting your sql w/o the keyword CURSOR doesn't mean you've avoided a performance bottleneck... likewise... just because you've coded to deallocate your cursor and think it to be done well doesn't mean some data will corrupt or crash your sproc or job that doesn't deallocate your cursor, locking away tables, rows or memory needed for your server. in your scenario... you can just reboot and restore your read-only db if it goes into suspect mode... that's not as much an option for other people on the list that need to have high availability and reliable dependable performance. On Thursday, September 23, 2010, jwcolby <jwcolby at colbyconsulting.com> wrote: > My goodness Francisco, don't you even read what you ask me to read? > > >Another cursor has been busted! Right? Actually ... no. You see, eliminating cursors is not about > syntax. > > LOL. > > >If that is the case, what have we just gained by replacing our CURSOR? Honestly -- not much, if > anything at all. Because of the task at hand, we may very well need to process rows in the Product > table one-by-one to send our emails and generate the report, and the bottleneck here is not the > cursor code at all > > ROTFL > > >Replacing a perfectly fine, simple cursor with a WHILE loop might even make your code longer, or > more confusing, or even less efficient depending on circumstances. > > Perfectly fine cursor??? LMAOBTC Did he really say "perfectly fine"? PLEASE tell me he didn't say > "simple". > > >how would we write this as a WHILE loop? Is it possible? Sure. Will it be as simple and clean > as using a cursor? No, it won't. (Though ROW_COUNT() makes this much easier than it used to be) > > OMG, he said it again! "Simple"? "Clean"? > > >Now, I am not here to say that cursors are "good", but if you really need to process rows one by > one, go ahead and proudly use a cursor. > > Uhh... am I missing something? So far nothing about system instability, nothing about crashing > servers... Lots about "simple, clean and use them proudly". If they are crashing every server in > sight why is this schmuck saying to use them? And why aren't you over there ragging on him? And > why are you telling me to read his stuff? What an IDIOT! (to quote Hermione) > > OK, enough! I never said that in this situation there wasn't a better solution. What I said was > that it is a tool, a simple tool, and one which will do this VERY SIMPLE job just fine if you want > to do it that way. > > Would it scale to a million records? Did I ever claim that it would? Did I not specifically state > that it shouldn't be used for that. Is that solution going to "tax his system". Seems rather > unlikely. Is it going to crash his system? Seems unlikely. Does it have to be done with a cursor? > Obviously not. > > As I said Fransicso, sometimes you crack me up. It's a tool for gods sake. It does simple things > simply. For all you SQL Gods (yes you Francisco) there are better solutions, which you can code > like I can code DAO. Unfortunately I am not a SQL (or any other kind of) god. > > And just because it seems to annoy you, I'll mention it again. > > I've been on this list for 15 years. > I've been on this list for 15 years. > I've been on this list for 15 years. > I've been on this list for 15 years. > I've been on this list for 15 years. > I've been on this list for 15 years. > > Bows low to the west, in the general direction of the ranking SQL God. > > ;) > > John W. Colby > www.ColbyConsulting.com > > On 9/23/2010 8:55 PM, Francisco Tapia wrote: >> Damn you John... >> You always have to throw in the number of years you've been on this >> list as if that means anything... > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://bit.ly/sqlthis | Tsql and More...