March 2, 2019 at 3:26 pm
Comments posted to this topic are about the item Defining Stored Procedures
March 2, 2019 at 5:16 pm
An easy one.
March 2, 2019 at 11:02 pm
Good question, nice reminder, thanks Steve.
...
March 4, 2019 at 12:54 am
Nice question, thanks Steve
____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
March 4, 2019 at 8:11 am
Nice easy question to start the week with. Reminds of a developer we had a few years ago. He pushed his first app to production and everything was broken. Kept getting error message that procedure X didn't exist. Every single thing in this app worked once and then crashed. Really had me shaking my head. Then started looking at the store procs that were created. Every one of them had a "if exists(....) drop procedure" at the end of them. When asked about why that was there I was told that they thought the begin/end would be sufficient. I was laughing so hard I nearly died. The code was literally eating itself as each time one procedure ran a different one was getting dropped. The big deployment script needed to have GO added in about a hundred places and redeploy the whole thing. 😀
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 4, 2019 at 9:29 am
Sean Lange - Monday, March 4, 2019 8:11 AMNice easy question to start the week with. Reminds of a developer we had a few years ago. He pushed his first app to production and everything was broken. Kept getting error message that procedure X didn't exist. Every single thing in this app worked once and then crashed. Really had me shaking my head. Then started looking at the store procs that were created. Every one of them had a "if exists(....) drop procedure" at the end of them. When asked about why that was there I was told that they thought the begin/end would be sufficient. I was laughing so hard I nearly died. The code was literally eating itself as each time one procedure ran a different one was getting dropped. The big deployment script needed to have GO added in about a hundred places and redeploy the whole thing. 😀
And that's one of the reasons that I don't like to use BEGIN...END to encapsulate procedures. Many of us have made a similar mistake and included lines of code that shouldn't be part of the procedure (although, this is the worst story I've seen).
March 4, 2019 at 10:32 am
Luis Cazares - Monday, March 4, 2019 9:29 AMSean Lange - Monday, March 4, 2019 8:11 AMNice easy question to start the week with. Reminds of a developer we had a few years ago. He pushed his first app to production and everything was broken. Kept getting error message that procedure X didn't exist. Every single thing in this app worked once and then crashed. Really had me shaking my head. Then started looking at the store procs that were created. Every one of them had a "if exists(....) drop procedure" at the end of them. When asked about why that was there I was told that they thought the begin/end would be sufficient. I was laughing so hard I nearly died. The code was literally eating itself as each time one procedure ran a different one was getting dropped. The big deployment script needed to have GO added in about a hundred places and redeploy the whole thing. 😀And that's one of the reasons that I don't like to use BEGIN...END to encapsulate procedures. Many of us have made a similar mistake and included lines of code that shouldn't be part of the procedure (although, this is the worst story I've seen).
I am not a big fan of begin end either. It seems it just causes an extra indentation with no benefit.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
March 4, 2019 at 10:32 am
Sean Lange - Monday, March 4, 2019 8:11 AMNice easy question to start the week with. Reminds of a developer we had a few years ago. He pushed his first app to production and everything was broken. Kept getting error message that procedure X didn't exist. Every single thing in this app worked once and then crashed. Really had me shaking my head. Then started looking at the store procs that were created. Every one of them had a "if exists(....) drop procedure" at the end of them. When asked about why that was there I was told that they thought the begin/end would be sufficient. I was laughing so hard I nearly died. The code was literally eating itself as each time one procedure ran a different one was getting dropped. The big deployment script needed to have GO added in about a hundred places and redeploy the whole thing. 😀
A number of years ago, I noticed stored procedures were running really slow, especially under a little bit of load (2 or 3 simultaneous connections). After inspecting the stored procedures in test, we had defined explicit permissions on the stored procs, and we typically add the permissions when we created the proc. Of course, the permissions were after the END, but there was no GO, so permissions were be re-added every time the proc ran. Clearing those out sped everything up...imagine that :hehe:
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply