2009-04-03 7 views
2

Ceci est moins une question de programmation et plus de quelques suggestions pour les outils :-) unScripts Empêcher SQL Server en cours d'exécution sur l'instance Mauvais

Je suis à la recherche d'un moyen d'éviter les scripts en cours d'exécution accidentellement sur la mauvaise instance de serveur SQL, c'est-à-dire que vous n'exécutez pas ce script pour supprimer les clients de votre environnement de développement dans l'environnement de production/direct. Ce que je suis essentiellement après est un branchement pour Enterprise Manager (ou une autre application pour gérer une instance de serveur sql), qui me permettrait de définir une liste de détails de connexion pour les instances du serveur SQL, de sorte que lorsque la fenêtre est connecté à un environnement LIVE qui le rend très clair, soit en coloriant l'onglet rouge, soit en faisant apparaître une boîte de message disant "Ceci est connecté à l'instance XXXX." Etes-vous sûr? "

Est-ce que quelqu'un a des idées pour des outils/plugins qui vont faire cela ou quoi que ce soit à distance?

Merci pour toute aide

Répondre

2

ici vous allez: http://www.ssmstoolspack.com/

ce Addin SSMS gratuit fournit des fenêtres coloration par serveur.

+0

acclamations, c'est exactement ce que j'étais après :-) –

0

Vous pouvez définir différents accès (limité) droit sur vous vivez par exemple pour l'utilisateur que vous utilisez habituellement. Et puis avoir un nom d'utilisateur différent pour faire des choses sérieuses sur le système en direct.

4

Tous mes scripts commencent par ceci:

if exists (select 1 from dbo.environment where value in('production', 'qa')) 
    return 

Bien sûr, cela signifie que j'ai une table d'environnement et ont la « production », le « développement », « qa », etc. en elle selon l'endroit où il est hébergé.

+0

+1 bonne suggestion –

+0

+1 Cela ressemble à une bonne idée. vous pourriez même utiliser quelque chose comme dire SI PAS EXISTE (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID (N '[dbo]. [present_only_in_test]')) return. De cette façon, vous n'aurez pas besoin de modifier le système de vie et ajouter seulement objet present_only_in_test dans test/développement env – kristof

+0

Semble que ce n'est pas complètement sûr cependant, voir la réponse par Andomar et des commentaires sur GO – kristof

1

Ce code vérifie SQL si vous êtes sur le bon serveur:

if @@servername <> 'testserver' 
    RAISERROR ('Wrong server', 16, 1); 

Une erreur (ou revenir à cette question), empêchera l'exécution jusqu'à ce que la prochaine instruction GO. Par exemple, ce qui suit encore imprimer Bonjour tout le monde, et supprimer la table utilisateur:

RAISERROR ('Wrong server', 16, 1); 
go 
drop table users 
print 'Hello world!' 
go 
+0

Bon point sur l'impact de GO – kristof

+0

Si le GO les instructions vous causent des problèmes, pensez à lancer une erreur comme celle-ci: 'RAISERROR ('NE PAS PASSER, PAS COLLECTER 200', 20, 1) AVEC LOG' Ceci mettra fin à votre session, même GO ne peut pas causer un autre lot courir. Pour fonctionner, il doit avoir une sévérité de 20 (pour les erreurs "fatales") et utiliser l'option 'WITH LOG'. Pour l'exécuter, vous devez être membre du rôle fixe sysadmin ou avoir les permissions ALTER TRACE. Inconvénient: Il va coller votre honte partout dans le journal des erreurs SQL Server ('sp_readerrorlog') et Windows Application Log. – SurroundedByFish

Questions connexes