My boss is an excellent programmer, unfortunately he writes
sql as he does code. He likes to call stored procedures from
other stored procedures, sometimes two or three levels deep.
He also likes to have one procedure being called by many different
sp. A very object orientated guy. Although this keeps the code fairly
clean it does not help performance. How can I persuade that
by eliminating the row by row approach to a more set based approach.
Ideas, articles, or just about anything that would help explain better my
point of view.

Nothing will work better than leading by example.

Take one of his poor performers, that uses a row-by-row approach, design it
more sensibly, and show him the difference...

Can you clarify what you mean, because having multiple stored procedures
call other procedures is usually pretty good.  The smaller the procedure the
easier to optimize.  Now using cursors is a whole 'nuther enchilada.
Leading by example as Aaron said is a great idea, especially if you can show
him the places where cursors have been particularly bad.  It really depends
on your boss' personality, if he is a good one, then just tell him, hey I
respect you but your code sucks.  If he is a jerk then get a new job.
Obviously he is most likely somewhere in between, but a person who likes to
code very object-orientedly probably does so because he understands that
discipline and does it because he knows what is right when building OO apps.
Let him know that what he is doing is wrong in this case, and that the
experts say so (not that I am calling myself an expert, but there are a lot
of people on here I respect who are very knowledgeable that will tell you
that cursors are evil :)

Show quoteHide quote

If it ain't broke, don't fix it!  Just how bad is performance?  A software
engineer has to weigh many different cost factors when designing and
implementing a system.  Depending on what the common procedures do,
separating the logic into the calling procedures can introduce code
redundancy--along with all of the additional development, testing, and
maintenance costs that are incurred.  On the other hand, a row-by-row
approach with long-running transactions can reduce concurrency, can
introduce deadlocks and can result in dreadful performance.  Management is
all about deciding which is the lesser of two evils, and that usually means
which costs less.

The real question you need to ask yourself is, "How far along is the
project?"  If two-thirds of the code is already written and tested, you may
want to just send a CYA memo or e-mail and then keep your mouth shut like a
good little programmer--at least until the project bombs and they start
looking for someone to fire.  If the project is in the early stages,
however, you may want to fill up his inbox with BOL and online articles on
optimizing performance and minimizing deadlocks.  Do a google search on "sql
cursor evil", "sql deadlock minimize", and "sql optimize performance" and
you'll find a plethora of articles by "experts" to fill his inbox with.

Show quoteHide quote

Stored Procs vs VIEWS: Seeking Comparison
How to find gaps in sequential key
boolean programming
Creating a trigger using a cursor
JDBC client - CURSOR as OUT parameter -supported ?