solving sql server problems for millions of dbas and developers since 2006



SQL Server DBA Tips SQL Server Developer Tips SQL Server Business Intelligence Tips SQL Server Career Tips SQL Server Tip Categories SQL Server Tutorials SQL Server Webcasts SQL Server Whitepapers SQL Server Tools SQL Server Questions and Answers MSSQLTips Authors About MSSQLTips SQL Server User Groups MSSLQTips Giveaways MSSQLTips Advertising Options

MSSQLTips Facebook Page MSSQLTips LinkedIn Page MSSQLTips RSS Feed MSSQLTips Twitter Page MSSQLTips Google+ Page








Preventing TSQL code from running on a Production SQL Server

By: | Read Comments | Print

Jeremy is the CTO @ Edgewood Solutions, co-founder of MSSQLTips.com and SQL Server MVP since 2009.



Related Tips: More

Problem
I have T-SQL code that I cannot have run on my production SQL Server.  How can I be sure that it does not run in production by mistake from a programmatic perspective rather than from a process perspective?  The reason I ask is because if the code ran in production, it would take us hours to get back up and running because we would need to go to our backup and then perform a number of restores.  The code that I am concerned about is responsible for purging particular data.  Although it is needed across our databases due to internal business requirements, I need a way to protect our production environment from this code being executed by mistake.  Any thoughts?

Solution
First and foremost, the best way to handle this item would be via a process, but if you need a quick and dirty option then check out some of them below:

  • SQL Server Instance Name
  • Database Name
  • Time Period

SQL Server Instance Name

If you have T-SQL code that would cause issues if it is run on your production SQL Server, then capturing the SQL Server name and issuing a RETURN command should do the trick.  What is necessary is to change your scripts and stored procedures to incorporate the appropriate logic.  Below are some potential examples:

-- Option 1
IF @@SERVERNAME = 'ProdSQL'
BEGIN
     PRINT '*** This code will NOT execute ***'
     RETURN
END

-- Option 2
IF @@SERVERNAME <> 'ProdSQL'
BEGIN
     PRINT '*** This code will NOT execute ***'
     RETURN
END

-- Option 3
IF @@SERVERNAME = 'ProdSQL'
BEGIN
     PRINT '*** This code will NOT execute ***'
     RETURN
END

ELSE

BEGIN
     PRINT '*** This code will execute ***'
END

Database Name

The same type of logic can be used if you have databases named by environment.  For example, your financial database is called Financial_Prod in your production environment, Financial_Test in the test environment, etc. then check out the following:

-- Option 1
IF DB_NAME() = 'Master'
BEGIN
     PRINT '*** This code will NOT execute ***'
     RETURN
END

-- Option 2
IF DB_NAME() <> 'Master'
BEGIN
     PRINT '*** This code will NOT execute ***'
     RETURN
END

-- Option 3
IF DB_NAME() = 'Master'
BEGIN
     PRINT '*** This code will NOT execute ***'
     RETURN
END

ELSE

BEGIN
     PRINT '*** This code will execute ***'
END

Time Period

If specific code cannot be run during specific time periods i.e. days of the week or hours of the day and for some reason it is not running via SQL Server Agent Job, then here is an option to prevent the code from executing on Saturday and Sunday:

-- Option 1 - If it is Sunday or Saturday, do not execute the code
IF DATEPART(dw,GETDATE()) = 1 OR DATEPART(dw,GETDATE()) = 7
BEGIN
     PRINT '*** This code will NOT execute ***'
     RETURN
END

Additional Information

To learn more about some of these commands, check out the following resources:

Next Steps

  • Identify code that would be problematic to issue in your production environments and consider changing your processes to prevent this code from being promoted to the incorrect environments.  If for business or application reasons that is not feasible immediately, then consider some of the options listed in this tip.
  • Depending on the exact circumstances of your environment dictates exactly how to use the commands listed in this tip in your T-SQL code.  You have a number of options with the native T-SQL functions and a fair amount of flexibility with the conditional logic.
  • Be sure to test and document the code thoroughly when you make a change like preventing code from executing.  If you or someone on your team skip a line or two of code when troubleshooting the code, then the analysis process can be long and frustrating.


Related Tips: More | Become a paid author


Last Update: 5/10/2007

Share: Share 






Comments and Feedback:


Post a Comment or Question

Keep it clean and stay on the subject or we may delete your comment.
Your email address is not published. Required fields are marked with an asterisk (*)

*Name   *Email   Notify for updates
Comments
*Enter Code refresh code


 
Sponsor Information
"SQL doctor ROCKS! As soon as I ran it, problems that have been giving me headaches were identified and cured."

It takes just 5 minutes to connect your SQL Databases to source control. Got 5 minutes? Get started now.

Need SQL Server help and not sure where to turn? Reach out to the Edgewood consultants for a Health Check.

Free Trial: Get Proactive Insight with Spotlight® for SQL Server Enterprise.

Solving SQL Server problems for millions of DBAs and Devs since 2006. Join now.

The SQL Server Security THREAT - It’s Closer Than You Think


Copyright (c) 2006-2012 Edgewood Solutions, LLC All rights reserved
privacy | disclaimer | copyright | advertise | about
authors | contribute | feedback | giveaways | user groups
Some names and products listed are the registered trademarks of their respective owners.


Edgewood Solutions LLC | MSSharePointTips.com | MSSQLTips.com