Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

There Must Be 15 Ways To Lose Your Cursors… Part 2: Just Put It in a S Expand / Collapse
Author
Message
Posted Monday, April 27, 2009 2:40 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, August 15, 2014 1:15 PM
Points: 337, Visits: 1,985
jwheeler (4/27/2009)

Then surely the manager hasn't done their job by employing the wrong tool for the task?

If you have database development to be done you either employ a db dev or a C# / VB developer who is also a SQL dev. You don't buy a hammer to put a screw in the wall, surely?


HR could well have given you the hammer and told you to get on with it
Internal shuffling is one way of minimising redundancies
Post #704775
Posted Monday, April 27, 2009 5:39 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Sunday, April 20, 2014 9:16 AM
Points: 29, Visits: 98
Hi

I still find I need Cursors when Sending out batches of Email notifications from the Server.

For example:

1. A scheduled Job selects records of people who need to be informed of some activity that has occurred - relevant data such as their email address, Name, the description of the activity etc is stored in variables using a CURSOR.

2. Inside the while loop I merge the data from the variables into an HTML Email template, and then send it out using dbMail.

I would love to replace this with set based handling but I can imagine how...particulary step 2

Adam
Post #704835
Posted Monday, April 27, 2009 5:44 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, August 15, 2014 1:15 PM
Points: 337, Visits: 1,985
atoth (4/27/2009)

I still find I need Cursors when Sending out batches of Email notifications from the Server.

I would love to replace this with set based handling but I can imagine how...particulary step 2

Adam


you're performing a procedural not a set based operation and the "per-row" function calls means that you will need to use a cursor.

Cursors do have their uses and this is one of them.
Post #704836
Posted Monday, April 27, 2009 6:36 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 9:09 AM
Points: 36,941, Visits: 31,443
Samuel Vella (4/27/2009)
atoth (4/27/2009)

I still find I need Cursors when Sending out batches of Email notifications from the Server.

I would love to replace this with set based handling but I can imagine how...particulary step 2

Adam


you're performing a procedural not a set based operation and the "per-row" function calls means that you will need to use a cursor.

Cursors do have their uses and this is one of them.


Heh... in SQL Server 2005, even that can be done without a cursor. We're just gonna have to wait for it in Barry's series of articles.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #704873
Posted Monday, April 27, 2009 6:37 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:46 AM
Points: 5,989, Visits: 12,916
nice work barry, you must have slaved other this. You should make a book out of all the chapters once you are done, as Lynn said it would become required reading.

I particularly like the rules for converting code to set based, useful mental prompts. Also the stats gathering method, although not applicable if using SQL 2000.


---------------------------------------------------------------------

Post #704875
Posted Monday, April 27, 2009 6:57 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
Another good one.

And on whatever the medical situation is, get well soon, man.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #704892
Posted Monday, April 27, 2009 7:25 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Thursday, September 5, 2013 2:13 PM
Points: 829, Visits: 4,099
Neat article and nicely written. I'm new to SQL but it's great to have this reference on how to change that procedural thought into a set thought.

By the way, the link to Part 1 is pointing to Part 2.

Good job and get well soon! Your fans eagerly await the next installment. :)


-- Kit
Post #704910
Posted Monday, April 27, 2009 7:33 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, August 15, 2014 1:15 PM
Points: 337, Visits: 1,985
Jeff Moden (4/27/2009)


Heh... in SQL Server 2005, even that can be done without a cursor. We're just gonna have to wait for it in Barry's series of articles.


OK it *can* be done without a cursor... I have seen some dirty work arounds to get stored procedure calls inside select statements using linked servers but they need certain security features turned on and would still end up as a row by row operation when processed within the database engine (not to mention all the other overheads associated with opening new DB connections) so no performance benefit.

IMO a last resort technique (even after the possibility of SSIS has been excluded).
Post #704915
Posted Monday, April 27, 2009 7:38 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, December 2, 2009 6:54 AM
Points: 7, Visits: 31
Writing a .net app to pull the dataset and iterate through it sending the mails would be faster than doing it in SQL, especially as merging the html template will involve some substring / replace activities (which in volume SQL isn't very fast at).

Depends on your volumes of course, if you are sending only a few thousand at a time a cursor or while loop would probably be fine.
Post #704918
Posted Monday, April 27, 2009 8:07 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 8:48 AM
Points: 1,304, Visits: 1,672
jwheeler (4/27/2009)
Samuel Vella (4/27/2009)
jwheeler (4/27/2009)
The fact you even have to tell so called developers this stuff is frightening.


Not really and it's something I've seen a few times...

When someone has a background in VB or C and has been dumped into SQL development then they might be able to write code but they lack the set based thinking which a good DB developer needs (they might not even be aware of being able to return sets depending on how much exposure they're had to databases in their previous life).

Usually a helping hand with their first few pieces of work will get them thinking the right way from the outset.

I know from experience when dabbling in ASP .NET that something which I've spent hours and several tens of lines of code trying to get to work can be ripped apart and rewritten as a very simple class by someone who knows what they're doing



Then surely the manager hasn't done their job by employing the wrong tool for the task?

If you have database development to be done you either employ a db dev or a C# / VB developer who is also a SQL dev. You don't buy a hammer to put a screw in the wall, surely?


That's a grossly oversimplified depiction. For a more realistic scenario, consider the following:

You're an IT manager for a medium-sized business, and you need a developer to build a custom database application -- but you've got almost no budget. You finally manage to convince the accountant to let you hire ONE developer.

Since you've got no budget, you do a little research and find the Visual Studio Express editions. You want to have some understanding of the created code, and you have some VB background. Now you've got a databse (SQL Server Express), a development environment (Visual Studio Express) and a development language (Visual Basic). So you put those requirements into your favorite jobs website and wait for your prince to come.

All of the responses you get back are specialized developers, SQL devs or VB devs who don't have a lot of db experience. What do you do?

From this (much more realistic) scenario, you should see that the problem is more like having a square bolt, and only having closed-end metric and standard hex wrenches. Sometimes none of the tools available to you fit the job quite right, and you have to pick the one that comes closest. Sometimes there's a tool you already have which isn't the right one but is a lot more easy to justify than spending $80k on a new tool for one job.

Of course the problem with all of these analogies is that we developers always come out looking like tools.
Post #704946
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse