Spécifier la connexion dans la requête T-SQL de Management Studio

Lors de l'ajout d'utilisateurs à des serveurs de bases de données, j'utilise souvent la fonction "Script cette action" de l'interface graphique. Je vais ensuite dans "Connection :: Change Connection" pour faire de même sur mes autres serveurs.

Existe-t-il un moyen de spécifier la connexion dans l'action scriptée afin de ne pas avoir à effectuer cette deuxième étape de modification de connexion?

Pas moyen de le faire dans le cadre d'un script de SSMS, mais vous avez deux options.

Une chose que vous pouvez faire est d'utiliser le mode SQLCMD et la commande :: connect afin d'avoir un script qui se connectera à plusieurs serveurs et exécutera le script. Cela fonctionne bien si vous enregistrez le script pour l'utilisateur et utilisez la commande: r pour charger le script à partir d'un fichier.

Vous pouvez également configurer un serveur de gestion central, puis exécuter votre script sur plusieurs serveurs à la fois.

En fait, c'est possible depuis T-SQL, mais vous devez remplir un certain ensemble de conditions et sauter à travers quelques cerceaux.

• Tout d'abord, vous devez activer les requêtes distantes (OPENDATASOURCE / OPENROWSET) sur le serveur à partir duquel les requêtes seront exécutées.
• Deuxièmement, vous devez vous assurer que l'accès à distance est activé sur les serveurs cibles.
• Troisièmement, vous devrez faire un usage intensif du SQL dynamique afin de pouvoir "injecter" du code T-SQL dans le moteur de base de données du serveur cible à exécuter.

Voici un exemple de script qui vous permettra d'utiliser le CMS pour automatiser les tâches SQL.

/**********************************************************************/

/* Global change password script                                      */

/*                                                                    */

/* This script changes the password for a SQL login on all servers    */

/* managed by a Central Management Server. It assumes that the login  */

/* exists on all servers, and that all servers are SQL 2005 or later. */

/**********************************************************************/

DECLARE @nServer NVARCHAR (128) -- Variable to hold the instance name retrieved from the CMS

DECLARE @nSQL NVARCHAR (4000)   -- Variable to hold dynamic SQL

DECLARE @ServerFetch INT        -- Variable to hold the fetch status. In SQL 2005, the @@FETCH_STATUS

                                -- variable is scoped at the system level, so if another process is also

                                -- using a cursor the @@FETCH_STATUS variable will be set according to

                                -- that operation. This allows us to store a persistent value.


DECLARE curServer CURSOR LOCAL STATIC FOR  -- Declare the cursor with the LOCAL and STATIC options, and

                                           -- retrieve the list of server names from the Central Management

                                           -- Server. The value in the [sysmanagement_shared_server_groups_internal]

                                           -- table is user-defined; for purposes of this example we have

                                           -- created a group named "SQL2008".

    SELECT DISTINCT

    s.server_name AS 'ServerName'

    FROM OPENDATASOURCE ('SQLOLEDB', 'Data Source = CMS1\Management; Integrated Security = SSPI').msdb.dbo.sysmanagement_shared_server_groups_internal g

    INNER JOIN OPENDATASOURCE ('SQLOLEDB', 'Data Source = CMS1\Management; Integrated Security = SSPI').msdb.dbo.sysmanagement_shared_registered_servers_internal s ON g.server_group_id = s.server_group_id

    WHERE g.name = 'SQL2008'

    ORDER BY s.server_name

OPEN curServer

FETCH FIRST FROM curServer INTO @nServer       -- Retrieve the first row

SET @ServerFetch = @@FETCH_STATUS              -- Store the status of the fetch operation

WHILE @ServerFetch = 0                         -- If the fetch was successful, we enter the loop. Otherwise

                                               -- execution passes to the statement following the END statement.

    BEGIN

    -- Build the dynamic SQL to alter the password for the SQL login.

    SET @nSQL = 'EXEC OPENDATASOURCE (''SQLOLEDB'', ''Data Source = ' + @nServer

        + '; Integrated Security = SSPI'').master.dbo.sp_executesql N''ALTER LOGIN SQLLogin WITH PASSWORD = ''''<enterStrongPasswordHere>'''''

    -- Execute the dynamic SQL.

    EXEC sp_executesql @nSQL

    FETCH NEXT FROM curServer INTO @nServer    -- Retrieve the next row.

    SET @ServerFetch = @@FETCH_STATUS          -- Store the status of the fetch operation.

    END

CLOSE curServer        -- Close the cursor.

DEALLOCATE curServer   -- Remove the cursor from memory.

Non. Seule la base de données par USE Database. Une connexion n'est pas scriptable.

SSMS 2008 (?) Et d'autres outils offrent la possibilité de "s'exécuter sur plusieurs serveurs". Désolé, je n'utilise pas cette fonctionnalité dans mon rôle actuel, je n'ai donc pas ce problème.