- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Just a temporary frist
Admin
The drop table statements are convenient when running the body of the procedure directly (not by calling the sproc), for debugging or new development. In that case, temp tables persist as long as your SSMS tab is open/connected, so you can't re-run the script multiple times without dropping the tables.
My personal preference, assuming a SQL Server version that supports the syntax, is to
drop table #foo if existsat the start of the sproc, and ideally to remember to put the drop table statements in a comment block before actually creating/altering the sproc.Admin
My eyes glaze over when it comes to good SQL, so I wound up fixating on "munge" in the article. Since my first text editor was TECO (which speaks to both my age and geekiness) I'm wanting desperately to scratch that "e" off the end of the word. Am I the only one to think that the code was "munging" the data, not "mungeing" it? (Curiously, dictionaries I checked say that "mungeing" is valid, but my browser's spell checker only says "munging" is correct.)
Admin
Hail TECO! I buit a screen-based custom visual editor with that.
And every good TECO hacker knows what their name does when typed at a command prompt.
Admin
TRWTF is the incorrect code highlighting. TDWTF is treating # as a comment marker.
Admin
Let's not forget the error handling. Since @@Error evaluates the statement immediately preceding it, the Select @@Error as ErrorNumber will always return 0 (assuming the begin after the if doesn't fail
Admin
and don't we love using a function on a column in order to use it in WHERE
Admin
heh, can't really follow this nor the article that well. About as clear as mud what the volume of data is in the XML before one can even make any assumptions about transaction handling, or perhaps more importantly, the number of rows in scope of the of transaction here. Obviously if the other devs came up with a simple solution, perhaps this person's comments and directives were simply an uneducated freak-out by a clueless person? Again, hard to say without knowing the picture of the data involved. But I'd definitely ding this code for looking like crap and having some nonsensical comments that are likely a red herring.