WHY IN GOD'S NAME do people write stored procedures that are like 12 pages
of code, doing such bizarrely convoluted looping and cursoring, all lower
case, no white space except for where it's required, no carriage returns,
and not a single comment about what it's for, or what it means or what it
does...

Honestly, this thing looks like some of those entries in the "Obfuscated C
Contests".

And then comment out the whole dang thing so that it does absolutey nothing,
not even a RETURN statement, and then leave it in the production database?!?

Does anything in the enterprise even still refer to it?!  Nobody knows.  Why
was it written?  Nobody knows.  Why was it fully commented out and then left
in place?  Nobody knows.  Maybe what I should do is rename the thing and
then watch for whole applications to fail.  But that's not safe either,
because if the frontside apps are written as badly as this stored procedure,
They might actually continue running without even being aware I changed its
name, with some idiotic error-ignoring code.


I need a friggen cigarette!

Sounds like where I work!  People use a brute-force method because they
don't enough SQL to do otherwise, but they know process-oriented thinking.
The problem is that SQL is NOT supposed to be a process-oriented thing, but
rather a set-oriented thing.  Any time I see such SQL as you've described, I
know what I am dealing with: upper-tier developers in the database.  I am
sure that they (1) put everything into temp tables. (2) declare cursors on
those temp tables (3) loop through the cursors and update/insert/delete
other temp tables (3) select from the results of all this thrashing-around
in tempdb.

You haeve my appreciation for your rant and my sympathy as well.

A. Corum

Show quoteHide quote

No, here's what they do.  I know this for a fact, because as a VB guy, and
an MCT, I have had THOUSANDS over the years in my classroom with all sorts
of VB-brain damage.  Here's the [mistaken] mental logic:

1. I just took a class, and learned how to mount a ADO recordset and then
make it a global variable, and then I can use data binding to connect it to
everything on the application.  If I acquire a read/write fulltime
connection at startup, and don't release anything ever, then my program runs
faster, because the connection, and the giant databound recordset are always
there.

2. I also read some article on the Internet, telling me that SQL Server is
really powerful, and I should have "thin clients"

3. So I write all my programs so that EVERYTHING happens on the server, and
my frontside app doesn't have to do anything other than srape the screen and
send all the stuff to my stored procedure.

4. COOL!  It reduced the volume of source code, and therefore makes my
client app run faster, AND!  AND -- AND, I didn't even have to bother
validating the inputs!  EXCELLENT!

5. WTF.  Hey, Mike Labosh?  We need you to come have a look at our systems,
because the server is behaving erratically.  We don't know why.  It's just
all slow and stuff, and there are duplicate records, and by the way, "what's
a table scan"?



After 10 years of crap like that, I am convinced of two things:

1. DBA's, Domain Admins and SENIOR developers worth their salt should be the
only ones that can CREATE PROCEDURE
2. We senior dev guys need to get off our asses and write more class
libraries to shield the data tier away from the Junior dev guys -- like
fluffy object models so they can have a "Customers Collection" that can bind
to their list box, without screwing with the backend.

Show quote Hide quote Here's what you're mental logic should be:

1. Sure, no problem!  My rate is $200 an hour, $300 after hours.

2. Cha-ching!

3. Ain't fishin' great!

Show quoteHide quote

SQL - maybe, but T-SQL is supposed to have the best of both worlds...

COUGH!-bullsh*t-COUGH!

Need I show you some of Bonnie's code?  I would rather not, because you
might accidentally shoot me.

Well, I've graduated in '86 and have been programing ever since. I've
seen it all, or almost all. Anyway, Ken Henderson in one of his book
says he used to think that T_SQL is supposed to be set oriented, but
changed his mind later. I like it...

hehe!! Another day in paradise eh?!!

Me too

Barry

A few weeks ago, I got an email from a guy who wants to write with
GOTOs ...

#include <yoda.h>
"Pain...Such pain...Death, I fear"


Even this VB-developer knows that GOTOs are the manifestation of Lucifer.

No, that's cursors.  GOTOs are minor demons.

Mike Labosh wrote:
Heh heh. Deep breaths, deep breaths. While I don't think I've come
across anything quite as bad as you describe in our system, I do have
Why! Why? Why!?!?! moments too when I look at past (and sometimes
present) developers' code. Some people just shouldn't be allowed to
write code, not until they pass a test or something.

That's precisely why I am MCSD Certified.  It documents and proves that I
will only *minorly* narf up your system with my code  :)

I could make you a list of people that are destined for Sheol because of
their actions within the database.

* It was written long ago.
* A consultant was called in to add to it.  Instead, he rewrote it.
* He was just there for a week, so left it in place as documentation,
but commented out as it wouldn't work anymore for the changed app.
* Unfortunately, this consultant, nor the original author, ever writes
any comments, or this would all be clear.

Have another hit - of fresh air.

Josh



On Sat, 29 Jul 2006 10:43:18 -0400, "Mike Labosh"
<mlabosh_at_hotmail_dot_com> wrote:
Show quoteHide quote

Deep SQL .Net integration question
any performance diff using -Between- or >= and <= ?
Spreadsheet totals
Foreign Key may cause multilple cycles
Bulk Insert from Excel