Temporary Stored Procedures

Jana Sattainathan discusses temporary stored procedures:

The real benefit of these procedures is when they contain lot of logic that you need on a temporary basis but do not want to clutter the existing stored procedure list. You could even have multiple temporary procedures that call each other. I would not go overboard with this. It is just a convenience.

I don’t often see these in use; when I’ve seen them, they’re in environments in which normal stored procedure create rights are locked down and you want to do something as a one-off (like testing an operation against production data).  In other words, those sketchy things that we don’t admit to each other that we do…

Related Posts

Tips For Debugging Large Procedures

Erik Darling has a few hints for debugging large stored procedures in SQL Server: Tip #1: Format Your Code There’s no shortage of free and paid tools out there. This list from the Recently Legendary Aaron Bertrand on Stack Exchange has both. This one alone is great.  Erik has several other tips as well.

Read More

Temp Table Caching And Reuse

Shane O’Neill ran into an error with his stored procedure call: We store the results in a temporary table first. Don’t worry, that’s not the end of the post. That’s not even the point of this post. It is, however, what I was doing when I came across a weird error. Let me show you! […]

Read More

1 Comment

  • Jana Sattainathan on 2016-10-20

    I agree with the dirty aspect! I too only use it for testing lest that I leave real stored procedures (used in testing) behind.

Comments are closed


October 2016
« Sep Nov »