EXECUTE (Transact-SQL)

Aktualisiert: 15. September 2007

Führt eine Befehlszeichenfolge oder eine Zeichenfolge in einem Transact-SQL-Batch oder eines der folgenden Module aus: gespeicherte Systemprozedur, benutzerdefinierte gespeicherte Prozedur, benutzerdefinierte Skalarwertfunktion oder eine erweiterte gespeicherte Prozedur.

Sicherheitshinweis:
Bevor Sie EXECUTE mit einer Zeichenfolge aufrufen, sollten Sie die Zeichenfolge überprüfen. Führen Sie auf keinen Fall einen aus Benutzereingaben erstellten Befehl aus, der nicht zuvor überprüft wurde. Weitere Informationen finden Sie unter SQL Injection.

SQL Server 2005 erweitert die EXECUTE-Anweisung, damit sie zum Senden von Pass-Through-Befehlen an Verbindungsserver verwendet werden kann. Darüber hinaus kann der Kontext, in dem eine Zeichenfolge oder ein Befehl ausgeführt wird, explizit festgelegt werden.

Transact-SQL-Syntaxkonventionen

Syntax

Execute a stored procedure or function
[ { EXEC | EXECUTE } ]
    { 
      [ @return_status = ]
      { module_name [ ;number ] | @module_name_var } 
        [ [ @parameter = ] { value 
                           | @variable [ OUTPUT ] 
                           | [ DEFAULT ] 
                           }
        ]
      [ ,...n ]
      [ WITH RECOMPILE ]
    }
[;]

Execute a character string
{ EXEC | EXECUTE } 
        ( { @string_variable | [ N ]'tsql_string' } [ + ...n ] )
    [ AS { LOGIN | USER } = ' name ' ]
[;]

Execute a pass-through command against a linked server
{ EXEC | EXECUTE }
        ( { @string_variable | [ N ] 'command_string [ ? ] ' } [ + ...n ]
        [ { , { value | @variable [ OUTPUT ] } } [ ...n ] ]
        ) 
    [ AS { LOGIN | USER } = ' name ' ]
    [ AT linked_server_name ]
[;]

Argumente

• **@**return_status
  Eine optionale ganzzahlige Variable, die den Rückgabestatus eines Moduls speichert. Diese Variable muss im Batch, in der gespeicherten Prozedur oder in der Funktion deklariert werden, bevor sie in einer EXECUTE-Anweisung verwendet wird.

  Bei der Verwendung zum Aufrufen einer benutzerdefinierten Skalarwertfunktion ist für die **@**return_status-Variable jeder skalare Datentyp möglich.

• module_name
  Der vollqualifizierte oder nicht vollqualifizierte Name der aufzurufenden gespeicherten Prozedur oder benutzerdefinierten Skalarwertfunktion. Modulnamen müssen den Regeln für Bezeichner entsprechen. Bei den Namen von erweiterten gespeicherten Prozeduren wird immer nach Groß-/Kleinschreibung unterschieden, unabhängig von der Sortierung des Servers.

  Ein Benutzer kann ein in einer anderen Datenbank erstelltes Modul ausführen, wenn er Besitzer des Moduls ist oder die entsprechende Berechtigung dafür hat, es in dieser Datenbank auszuführen. Ein Benutzer kann ein Modul auf einem anderen Server mit SQL Server ausführen, wenn er die entsprechende Berechtigung besitzt, diesen Server zu verwenden (Remotezugriff) und das Modul in dieser Datenbank auszuführen. Wird ein Servername, aber kein Datenbankname angegeben, sucht SQL Server 2005-Datenbankmodul das Modul in der Standarddatenbank des Benutzers.

• **;**number
  Eine optionale ganze Zahl zum Gruppieren von Prozeduren mit dem gleichen Namen. Dieser Parameter wird nicht bei erweiterten gespeicherten Prozeduren verwendet.

  Hinweis:
  Dieses Feature wird in einer zukünftigen Version von Microsoft SQL Server entfernt. Verwenden Sie dieses Feature beim Entwickeln neuer Anwendungen nicht, und planen Sie das Ändern von Anwendungen, in denen es zurzeit verwendet wird.

  Weitere Informationen zu Prozedurgruppen finden Sie unter CREATE PROCEDURE (Transact-SQL).

• **@**module_name_var
  Der Name einer lokal definierten Variablen, die den Namen eines Moduls darstellt.

• **@**parameter
  Der Parameter für module_name, wie er im Modul definiert ist. Parameternamen muss das @-Zeichen vorangestellt werden. Wird das Format **@**parameter_name=value verwendet, müssen Parameternamen und Konstanten nicht in der Reihenfolge angegeben werden, wie sie im Modul definiert sind. Wenn allerdings das Format **@**parameter_name=value für einen Parameter verwendet wird, dann ist dies auch für alle nachfolgenden Parameter erforderlich.

  Für Parameter sind standardmäßig NULL-Werte zugelassen. Wenn als Parameterwert NULL übergeben wird und dieser Parameter in einer CREATE TABLE- oder ALTER TABLE-Anweisung auf eine Spalte verweist, die keine NULL-Werte zulässt (z. B. beim Einfügen in eine Spalte, die keine NULL-Werte zulässt), löst Datenbankmodul einen Fehler aus. Um zu verhindern, dass ein NULL-Parameterwert an eine Spalte übergeben wird, die keine NULL-Werte zulässt, fügen Sie dem Modul entweder Programmierlogik hinzu oder verwenden (mit dem DEFAULT-Schlüsselwort der CREATE TABLE- oder ALTER TABLE-Anweisung) einen Standardwert für die Spalte.

• value
  Der Wert des Parameters, der an das Modul oder den Pass-Through-Befehl übergeben werden soll. Wenn keine Parameternamen angegeben werden, müssen die Parameterwerte in der Reihenfolge angegeben werden, in der sie im Modul definiert sind.

  Wenn Sie Pass-Through-Befehle für Verbindungsserver ausführen, hängt die Reihenfolge der Parameterwerte vom OLE DB-Anbieter des Verbindungsservers ab. Die meisten OLE DB-Anbieter binden Werte von links nach rechts an Parameter.

  Wenn der Wert eines Parameters ein Objektname oder eine Zeichenfolge ist oder durch den Namen einer Datenbank oder eines Schemas qualifiziert ist, dann muss der gesamte Name in einfache Anführungszeichen eingeschlossen werden. Ist der Wert eines Parameters ein Schlüsselwort, muss das Schlüsselwort in doppelte Anführungszeichen eingeschlossen werden.

  Falls im Modul ein Standardwert definiert ist, kann ein Benutzer das Modul ohne Angabe von Parametern ausführen.

  Der Standardwert kann auch NULL sein. Im Allgemeinen gibt die Moduldefinition die Aktion an, die ausgeführt werden soll, wenn ein Parameter den Wert NULL hat.

• **@**variable
  Die Variable, die einen Parameter oder einen Rückgabeparameter speichert.

• OUTPUT
  Gibt an, dass das Modul oder die Befehlszeichenfolge einen Parameter zurückgibt. Der entsprechende Parameter im Modul oder in der Befehlszeichenfolge muss ebenfalls mit dem OUTPUT-Schlüsselwort erstellt worden sein. Dieses Schlüsselwort sollte verwendet werden, wenn Cursorvariablen als Parameter verwendet werden.

  Wenn value als OUTPUT eines Moduls definiert ist, das für einen Verbindungsserver ausgeführt wird, werden alle vom OLE DB-Anbieter vorgenommenen Änderungen am entsprechenden **@**parameter am Ende der Ausführung des Moduls an die Variable zurückkopiert.

  Wenn OUTPUT-Parameter verwendet werden und die Rückgabewerte in anderen Anweisungen innerhalb des aufrufenden Batches oder Moduls verwendet werden sollen, dann muss der Wert des Parameters als Variable übergeben werden (d. h., im Format **@**parameter = **@**variable). Sie können ein Modul nicht mit der Angabe von OUTPUT für einen Parameter ausführen, der nicht als OUTPUT-Parameter im Modul definiert wurde. Konstanten können nicht mit OUTPUT an ein Modul übergeben werden; der Rückgabeparameter erfordert einen Variablennamen. Vor dem Ausführen der Prozedur muss der Datentyp der Variablen deklariert und ihr ein Wert zugewiesen werden.

  Wenn EXECUTE für eine remote gespeicherte Prozedur verwendet wird, oder um einen Pass-Through-Befehl für einen Verbindungsserver auszuführen, können OUTPUT-Parameter nicht einen der LOB-Datentypen (Large Object) aufweisen.

  Rückgabeparameter können von einem beliebigen Datentyp außer den LOB-Datentypen sein.

• DEFAULT
  Gibt den im Modul definierten Standardwert des Parameters an. Wenn das Modul einen Wert für einen Parameter erwartet, der keinen definierten Standardwert aufweist, und entweder ein Parameter fehlt oder das DEFAULT-Schlüsselwort angegeben ist, tritt ein Fehler auf.

• WITH RECOMPILE
  Erzwingt, dass ein neuer Abfrageplan kompiliert, verwendet und nach der Ausführung des Moduls verworfen wird. Falls bereits ein Abfrageplan für das Modul vorhanden ist, verbleibt dieser Plan im Cache.

  Verwenden Sie diese Option, wenn der von Ihnen angegebene Parameter atypisch ist oder sich die Daten erheblich geändert haben. Diese Option wird nicht bei erweiterten gespeicherten Prozeduren verwendet. Es wird empfohlen, diese Option nur selten zu verwenden, da sie aufwändig ist.

  Hinweis:
  Sie können WITH RECOMPILE nicht verwenden, wenn Sie eine gespeicherte Prozedur aufrufen, die OPENDATASOURCE-Syntax verwendet. Die Option WITH RECOMPILE wird ignoriert, wenn ein vierteiliger Objektname angegeben wird.

• **@**string_variable
  Der Name einer lokalen Variablen. **@**string_variable kann vom Datentyp char, varchar, nchar oder nvarchar sein. Hierzu zählen auch die Datentypen (max).

• [N] 'tsql_string'
  Eine Konstantenzeichenfolge. tsql_string kann vom Datentyp nvarchar oder varchar sein. Wird das N angegeben, wird die Zeichenfolge als Datentyp nvarchar interpretiert.

• AS <context_specification>
  Gibt den Kontext an, in dem die Anweisung ausgeführt wird. Weitere Informationen finden Sie unter Grundlegendes zum Ausführungskontext.

• LOGIN
  Gibt an, dass der Kontext, der als Identität angenommen werden soll, ein Anmeldename ist. Der Identitätswechselbereich ist der Server.

• USER
  Gibt an, dass der Kontext, der als Identität angenommen werden soll, ein Benutzer in der aktuellen Datenbank ist. Der Identitätswechselbereich ist auf die aktuelle Datenbank beschränkt. Bei einem Kontextwechsel zu einem Datenbankbenutzer werden die Berechtigungen auf Serverebene dieses Benutzers nicht geerbt.

  Wichtig:

  Während der Kontextwechsel zu dem Datenbankbenutzer aktiv ist, wird bei jedem Zugriffsversuch auf Ressourcen außerhalb der Datenbank für die Anweisung ein Fehler gemeldet. Hierzu zählen USE database-Anweisungen, verteilte Abfragen und Abfragen, die auf eine andere Datenbank mithilfe von drei- und vierteiligen Bezeichnern verweisen. Weitere Informationen zum Erweitern des Bereichs für den Kontextwechsel über die aktuelle Datenbank hinaus finden Sie unter Erweitern des Identitätswechsels bei Datenbanken durch Verwenden von EXECUTE AS.

• 'name'
  Ein gültiger Benutzer oder Anmeldename. name muss ein Mitglied der festen Serverrolle sysadmin sein oder als Prinzipal in sys.database_principals bzw. sys.server_principals vorhanden sein.

  name kann kein integriertes Konto sein, wie z. B. NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService oder NT AUTHORITY\LocalSystem.

  Weitere Informationen finden Sie unter Angeben eines Benutzers oder eines Anmeldenamens weiter unten in diesem Thema.

• [N] 'command_string'
  Eine Konstantenzeichenfolge, die den Befehl enthält, der über den Verbindungsserver übergeben werden soll . Wird das N angegeben, wird die Zeichenfolge als Datentyp nvarchar interpretiert.

• [?]
  Gibt Parameter an, deren Werte im <arg-list>-Parameter von Pass-Through-Befehlen bereitgestellt werden, die in einer EXEC('…', <arg-list>) AT <linkedsrv>-Anweisung verwendet werden.

• AT linked_server_name
  Gibt an, dass command_string für linked_server_name ausgeführt wird und dass Ergebnisse (soweit vorhanden) an den Client zurückgegeben werden. linked_server_name muss auf eine vorhandene Verbindungsserverdefinition auf dem lokalen Server verweisen. Verbindungsserver werden mithilfe von sp_addlinkedserver definiert.

Hinweise

Parameter können mithilfe von value oder **@parameter_name=**value. angegeben werden. Ein Parameter ist nicht Teil einer Transaktion. Deshalb wird der Wert eines Parameters, der in einer Transaktion geändert wird, nicht wieder auf seinen ursprünglichen Wert zurückgesetzt, wenn für diese Transaktion später ein Rollback ausgeführt wird. Der Wert, der an den Aufrufer zurückgegeben wird, ist immer der Wert zu dem Zeitpunkt, zu dem das Modul beendet wird.

Die Schachtelung erfolgt, wenn ein Modul ein anderes Modul aufruft oder verwalteten Code durch Verweis auf ein CLR-Modul (Common Language Runtime), einen benutzerdefinierten Typ oder ein Aggregat ausführt. Die Schachtelungsebene wird um eins erhöht, wenn das aufgerufene Modul oder der Verweis auf den verwalteten Code mit der Ausführung beginnt, und wird wieder um eins erniedrigt, wenn das aufgerufene Modul oder der Verweis auf den verwalteten Code beendet ist. Ein Überschreiten der maximal möglichen 32 Schachtelungsebenen führt zu einem Fehler der gesamten Aufrufskette. Die aktuelle Schachtelungsebene wird in der @@NESTLEVEL-Systemfunktion gespeichert.

Da remote gespeicherte Prozeduren und erweiterte gespeicherte Prozeduren außerhalb des Bereichs einer Transaktion liegen (es sei denn, sie werden innerhalb einer BEGIN DISTRIBUTED TRANSACTION-Anweisung ausgegeben oder mit diversen Konfigurationsoptionen verwendet), kann für Befehle, die durch das Aufrufen solcher Prozeduren ausgeführt werden, kein Rollback ausgeführt werden. Weitere Informationen finden Sie unter Gespeicherte Systemprozeduren (Transact-SQL) und BEGIN DISTRIBUTED TRANSACTION (Transact-SQL).

Wird beim Verwenden von Cursorvariablen eine Prozedur ausgeführt, die eine Cursorvariable übergibt, für die ein Cursor zugeordnet ist, tritt ein Fehler auf.

Sie müssen das EXECUTE-Schlüsselwort beim Ausführen von Modulen nicht angeben, wenn es sich dabei um die erste Anweisung in einem Batch handelt.

Verwenden von EXECUTE mit gespeicherten Prozeduren

Sie müssen das EXECUTE-Schlüsselwort beim Ausführen von gespeicherten Prozeduren nicht angeben, wenn es sich dabei um die erste Anweisung in einem Batch handelt.

Gespeicherte Systemprozeduren von SQL Server beginnen mit den Zeichen sp_. Sie werden physikalisch in der Ressourcendatenbank gespeichert, werden aber logisch im sys-Schema jeder Systemdatenbank und benutzerdefinierten Datenbank angezeigt. Es wird empfohlen, den Namen der gespeicherten Prozedur mit dem sys-Schemanamen zu qualifizieren, wenn Sie eine gespeicherte Prozedur ausführen, entweder in einem Batch oder innerhalb eines Moduls, wie etwa eine benutzerdefinierte gespeicherte Prozedur oder Funktion.

Erweiterte gespeicherte Systemprozeduren von SQL Server beginnen mit den Zeichen xp_ und sind im dbo-Schema der master-Datenbank enthalten. Es wird empfohlen, den Namen der gespeicherten Prozedur mit master.dbo zu qualifizieren, wenn Sie eine erweiterte gespeicherte Prozedur ausführen, entweder in einem Batch oder innerhalb eines Moduls, wie etwa eine benutzerdefinierte gespeicherte Prozedur oder Funktion.

Es wird empfohlen, den Namen der gespeicherten Prozedur mit einem Schemanamen zu qualifizieren, wenn Sie eine benutzerdefinierte gespeicherte Prozedur ausführen, entweder in einem Batch oder innerhalb eines Moduls, wie etwa eine benutzerdefinierte gespeicherte Prozedur oder Funktion. Wir raten davon ab, für eine benutzerdefinierte gespeicherte Prozedur den gleichen Namen wie für eine gespeicherte Systemprozedur zu verwenden. Weitere Informationen zum Ausführen gespeicherter Prozeduren finden Sie unter Ausführen von gespeicherten Prozeduren (Datenbankmodul).

Verwenden von EXECUTE mit einer Zeichenfolge

In früheren Versionen von SQL Server sind Zeichenfolgen auf 8.000 Bytes beschränkt. Deshalb müssen lange Zeichenfolgen für die dynamische Ausführung verkettet werden. In SQL Server 2005 können die Datentypen varchar(max) und nvarchar(max) angegeben werden, die Zeichenfolgen mit bis zu 2 GB an Daten zulassen.

Eine Änderung des Datenbankkontexts dauert nur so lange, bis die jeweilige EXECUTE-Anweisung beendet ist. Beispielsweise lautet nach der Ausführung von EXEC in der folgenden Anweisung der Datenbankkontext master.

USE master; EXEC ('USE AdventureWorks; SELECT EmployeeID, Title FROM HumanResources.Employee;');

Kontextwechsel

Mithilfe der AS { LOGIN | USER } = ' name '-Klausel können Sie den Ausführungskontext einer dynamischen Anweisung wechseln. Wenn der Kontextwechsel als EXECUTE ('string') AS <context_specification> angegeben wird, ist die Dauer des Kontextwechsels auf den Bereich der ausgeführten Abfrage beschränkt. Weitere Informationen finden Sie unter Grundlegendes zum Wechseln des Kontexts.

Angeben eines Benutzers oder eines Anmeldenamens

Der in AS { LOGIN | USER } = ' name ' angegebene Benutzer oder Anmeldename muss als Prinzipal in sys.database_principals bzw. sys.server_principals vorhanden sein. Andernfalls wird für die Anweisung ein Fehler gemeldet. Darüber hinaus müssen dem Prinzipal IMPERSONATE-Berechtigungen erteilt werden. Der Prinzipal muss vorhanden sein, selbst wenn der Benutzer über eine Windows-Gruppenmitgliedschaft auf die Datenbank oder die Instanz von SQL Server zugreift, außer der Aufrufer ist der Datenbankbesitzer oder ein Mitglied der festen Serverrolle sysadmin. Stellen Sie sich z. B. folgende Bedingungen vor:

• Die CompanyDomain\SQLUsers-Gruppe hat Zugriff auf die Sales-Datenbank.
• CompanyDomain\SqlUser1 ist ein Mitglied von SQLUsers und hat deshalb impliziten Zugriff auf die Sales-Datenbank.

Obwohl CompanyDomain\SqlUser1 über die Mitgliedschaft in der SQLUsers-Gruppe Zugriff auf die Datenbank hat, wird für die Anweisung EXECUTE @string_variable AS USER = 'CompanyDomain\SqlUser1' ein Fehler gemeldet, weil CompanyDomain\SqlUser1 nicht als Prinzipal in der Datenbank vorhanden ist.

Bewährte Methoden

Geben Sie einen Anmeldenamen oder einen Benutzer an, der die mindestens erforderlichen Privilegien zum Ausführen der in der Anweisung oder im Modul definierten Vorgänge aufweist. Geben Sie z. B. keinen Anmeldenamen an, der über Berechtigungen auf Serverebene verfügt, wenn nur Berechtigungen auf Datenbankebene notwendig sind; oder geben Sie nur ein Datenbankbesitzer-Konto an, wenn diese Berechtigungen erforderlich sind.

Berechtigungen

Zum Ausführen der EXECUTE-Anweisung sind keine Berechtigungen erforderlich. Es sind jedoch Berechtigungen für die sicherungsfähigen Elemente erforderlich, auf die in der EXECUTE-Zeichenfolge verwiesen wird. Wenn z. B. die Zeichenfolge eine INSERT-Anweisung enthält, benötigt der Aufrufer der EXECUTE-Anweisung die INSERT-Berechtigung für die Zieltabelle. Berechtigungen werden überprüft, wenn die EXECUTE-Anweisung erreicht wird, selbst wenn die EXECUTE-Anweisung innerhalb eines Moduls enthalten ist.

EXECUTE-Berechtigungen für ein Modul liegen standardmäßig beim Besitzer dieses Moduls. Der Besitzer kann die Berechtigungen an andere Benutzer übertragen. Wird ein Modul ausgeführt, das eine Zeichenfolge ausführt, werden Berechtigungen im Kontext des Benutzers geprüft, der das Modul ausführt, nicht im Kontext des Benutzers, der das Modul erstellt hat. Wenn jedoch derselbe Benutzer Besitzer des aufrufenden Moduls und des aufgerufenen Moduls ist, wird die EXECUTE-Berechtigung für das zweite Modul nicht mehr überprüft. Weitere Informationen finden Sie unter Besitzketten.

Wenn das Modul auf andere Datenbankobjekte zugreift, ist die Ausführung erfolgreich, wenn Sie die EXECUTE-Berechtigung für das Modul haben und eine der folgenden Bedingungen zutrifft:

• Das Modul ist als EXECUTE AS USER oder SELF gekennzeichnet, und der Modulbesitzer besitzt die entsprechenden Berechtigungen für das Objekt, auf das verwiesen wird.
• Das Modul ist als EXECUTE AS CALLER gekennzeichnet, und Sie besitzen die entsprechenden Berechtigungen für das Objekt.
• Das Modul ist als EXECUTE AS user_name gekennzeichnet, und user_name besitzt die entsprechenden Berechtigungen für das Objekt.

Berechtigungen für den Kontextwechsel

Um EXECUTE AS für einen Anmeldenamen anzugeben, benötigt der Aufrufer IMPERSONATE-Berechtigungen für den angegebenen Anmeldenamen. Um EXECUTE AS für einen Datenbankbenutzer anzugeben, benötigt der Aufrufer IMPERSONATE-Berechtigungen für den angegebenen Benutzernamen. Wenn kein Ausführungskontext angegeben ist oder wenn EXECUTE AS CALLER angegeben ist, sind keine IMPERSONATE-Berechtigungen erforderlich.

Beispiele

A. Verwenden von EXECUTE, um einen einzelnen Parameter zu übergeben

Die gespeicherte Prozedur uspGetEmployeeManagers erwartet einen Parameter (@EmployeeID). Die folgenden Beispiele führen die gespeicherte Prozedur uspGetEmployeeManagers mit Employee ID 6 als Parameterwert aus.

USE AdventureWorks;
GO
EXEC dbo.uspGetEmployeeManagers 6;
GO

Die Variable kann bei der Ausführung auch ausdrücklich benannt werden:

EXEC dbo.uspGetEmployeeManagers @EmployeeID = 6;
GO

Falls es sich bei der folgenden Anweisung um die erste Anweisung in einem Batch oder in einem osql- oder sqlcmd-Skript handelt, ist die Angabe von EXEC nicht erforderlich.

dbo.uspGetEmployeeManagers 6;
GO
--Or
dbo.uspGetEmployeeManagers @EmployeeID = 6;
GO

B. Verwenden mehrerer Parameter

Im folgenden Beispiel wird die gespeicherte Prozedur spGetWhereUsedProductID ausgeführt. Sie übergibt zwei Parameter: Der erste Parameter ist eine Produkt-ID (819), und der zweite Parameter, @CheckDate, ist ein datetime-Wert.

USE AdventureWorks;
GO
DECLARE @CheckDate datetime;
SET @CheckDate = GETDATE();
EXEC dbo.uspGetWhereUsedProductID 819, @CheckDate;
GO

C. Verwenden von EXECUTE 'tsql_string' mit einer Variablen

Das folgende Beispiel zeigt, wie EXECUTE dynamisch erstellte Zeichenfolgen behandelt, die Variablen enthalten. Dieses Beispiel erstellt den tables_cursor-Cursor, der eine Liste aller benutzerdefinierten Tabellen in der AdventureWorks-Datenbank enthält. Anschließend werden mithilfe dieser Liste alle Indizes für die Tabellen neu erstellt.

USE AdventureWorks;
GO
DECLARE tables_cursor CURSOR
   FOR
   SELECT s.name, t.name 
   FROM sys.objects AS t
   JOIN sys.schemas AS s ON s.schema_id = t.schema_id
   WHERE t.type = 'U';
OPEN tables_cursor;
DECLARE @schemaname sysname;
DECLARE @tablename sysname;
FETCH NEXT FROM tables_cursor INTO @schemaname, @tablename;
WHILE (@@FETCH_STATUS <> -1)
BEGIN;
   EXEC ('ALTER INDEX ALL ON ' + @schemaname + '.' + @tablename + ' REBUILD;');
   FETCH NEXT FROM tables_cursor INTO @schemaname, @tablename;
END;
PRINT 'The indexes on all tables have been rebuilt.';
CLOSE tables_cursor;
DEALLOCATE tables_cursor;
GO

D. Verwenden von EXECUTE mit einer remote gespeicherten Prozedur

Das folgende Beispiel führt die gespeicherte Prozedur uspGetEmployeeManagers auf dem Remoteserver SQLSERVER1 aus und speichert den Rückgabestatus, der anzeigt, ob die Ausführung erfolgreich war oder nicht, in @retstat.

DECLARE @retstat int;
EXECUTE @retstat = SQLSERVER1.AdventureWorks.dbo.uspGetEmployeeManagers @EmployeeID = 6;

E. Verwenden von EXECUTE mit einer Variablen für eine gespeicherte Prozedur

Das folgende Beispiel erstellt eine Variable, die den Namen einer gespeicherten Prozedur darstellt.

DECLARE @proc_name varchar(30);
SET @proc_name = 'sys.sp_who';
EXEC @proc_name;

F. Verwenden von EXECUTE mit DEFAULT

Das folgende Beispiel erstellt eine gespeicherte Prozedur mit Standardwerten für den ersten und dritten Parameter. Beim Ausführen der Prozedur werden diese Standardwerte für den ersten und dritten Parameter eingefügt, falls beim Aufruf kein Wert übergeben oder DEFAULT angegeben wird. Beachten Sie, wie verschiedenartig das DEFAULT-Schlüsselwort verwendet werden kann.

USE AdventureWorks;
GO
IF OBJECT_ID(N'dbo.ProcTestDefaults', N'P')IS NOT NULL
   DROP PROCEDURE dbo.ProcTestDefaults;
GO
-- Create the stored procedure.
CREATE PROCEDURE dbo.ProcTestDefaults (
@p1 smallint = 42, 
@p2 char(1), 
@p3 varchar(8) = 'CAR')
AS 
   SET NOCOUNT ON;
   SELECT @p1, @p2, @p3
;
GO

Die gespeicherte Prozedur Proc_Test_Defaults kann in verschiedenen Kombinationen ausgeführt werden.

-- Specifying a value only for one parameter (@p2).
EXECUTE dbo.ProcTestDefaults @p2 = 'A';
-- Specifying a value for the first two parameters.
EXECUTE dbo.ProcTestDefaults 68, 'B';
-- Specifying a value for all three parameters.
EXECUTE dbo.ProcTestDefaults 68, 'C', 'House';
-- Using the DEFAULT keyword for the first parameter.
EXECUTE dbo.ProcTestDefaults @p1 = DEFAULT, @p2 = 'D';
-- Specifying the parameters in an order different from the order defined in the procedure.
EXECUTE dbo.ProcTestDefaults DEFAULT, @p3 = 'Local', @p2 = 'E';
-- Using the DEFAULT keyword for the first and third parameters.
EXECUTE dbo.ProcTestDefaults DEFAULT, 'H', DEFAULT;
EXECUTE dbo.ProcTestDefaults DEFAULT, 'I', @p3 = DEFAULT;

G. Verwenden von EXECUTE mit AT linked_server_name

Das folgende Beispiel übergibt eine Befehlszeichenfolge an einen Remoteserver. Der Verbindungsserver SeattleSales wird erstellt, der auf eine andere Instanz von SQL Server verweist und eine DDL-Anweisung (CREATE TABLE) auf diesem Verbindungsserver ausführt.

EXEC sp_addlinkedserver 'SeattleSales', 'SQL Server'
GO
EXECUTE ( 'CREATE TABLE AdventureWorks.dbo.SalesTbl 
(SalesID int, SalesName varchar(10)) ; ' ) AT SeattleSales;
GO

H. Verwenden von EXECUTE WITH RECOMPILE

Das folgende Beispiel führt die gespeicherte Prozedur Proc_Test_Defaults aus und erzwingt, dass ein neuer Abfrageplan kompiliert, verwendet und nach der Ausführung des Moduls verworfen wird.

EXECUTE dbo.Proc_Test_Defaults @p2 = 'A' WITH RECOMPILE;
GO

I. Verwenden von EXECUTE mit einer benutzerdefinierten Funktion

Im folgenden Beispiel wird die benutzerdefinierte Skalarfunktion ufnGetSalesOrderStatusText ausgeführt. Die @returnstatus-Variable wird zum Speichern des Wertes verwendet, der von der Funktion zurückgegeben wird. Diese Funktion erwartet einen Eingabeparameter, @Status. Für diesen ist der Datentyp tinyint definiert.

USE AdventureWorks;
GO
DECLARE @returnstatus nvarchar(15);
SET @returnstatus = NULL;
EXEC @returnstatus = dbo.ufnGetSalesOrderStatusText @Status = 2;
PRINT @returnstatus;
GO

J. Verwenden von EXECUTE zum Abfragen einer Oracle-Datenbank auf einem Verbindungsserver

Das folgende Beispiel führt mehrere SELECT-Anweisungen auf dem Oracle-Remoteserver aus. Zunächst wird der Oracle-Server als Verbindungsserver hinzugefügt und der Anmeldename für den Verbindungsserver erstellt.

-- Setup the linked server.
EXEC sp_addlinkedserver  
        @server='ORACLE',
        @srvproduct='Oracle',
        @provider='OraOLEDB.Oracle', 
        @datasrc='ORACLE10';

EXEC sp_addlinkedsrvlogin 
    @rmtsrvname='ORACLE',
    @useself='false', 
    @locallogin=null, 
    @rmtuser='scott', 
    @rmtpassword='tiger';
 
EXEC sp_serveroption 'ORACLE', 'rpc out', true;
GO
 
-- Execute several statements on the linked Oracle server.
EXEC ( 'SELECT * FROM scott.emp') AT ORACLE;
GO
EXEC ( 'SELECT * FROM scott.emp WHERE MGR = ?', 7902) AT ORACLE;
GO
DECLARE @v INT; 
SET @v = 7902;
EXEC ( 'SELECT * FROM scott.emp WHERE MGR = ?', @v) AT ORACLE;
GO

K. Verwenden von EXECUTE AS USER zum Wechseln des Kontexts zu einem anderen Benutzer

Das folgende Beispiel führt eine Transact-SQL-Zeichenfolge aus, mit der eine Tabelle erstellt und die AS USER-Klausel zum Umschalten des Ausführungskontexts der Anweisung vom Aufrufer zu User1 angegeben wird. Datenbankmodul überprüft die Berechtigungen von User1, wenn die Anweisung ausgeführt wird. User1 muss als Benutzer in der Datenbank vorhanden sein und benötigt die Berechtigung zum Erstellen von Tabellen im Sales-Schema. Andernfalls kann die Anweisung nicht ausgeführt werden.

USE AdventureWorks;
GO
EXECUTE ('CREATE TABLE Sales.SalesTable (SalesID int, SalesName varchar(10));')
AS USER = 'User1';
GO

L. Verwenden eines Parameters mit EXECUTE und AT linked_server_name

Im folgenden Beispiel wird eine Befehlszeichenfolge an einen Remoteserver übergeben, indem ein Fragezeichen (?) als Platzhalter für einen Parameter verwendet wird. Im Beispiel wird zunächst ein Verbindungsserver SeattleSales erstellt, der auf eine andere Instanz von SQL Server verweist. Anschließend wird eine SELECT-Anweisung auf diesem Verbindungsserver ausgeführt. In der SELECT-Anweisung wird das Fragezeichen als Platzhalter für den ProductID-Parameter (952) verwendet, der hinter der Anweisung angegeben wird.

-- Setup the linked server.
EXEC sp_addlinkedserver 'SeattleSales', 'SQL Server'
GO
-- Execute the SELECT statement.
EXECUTE ('SELECT ProductID, Name 
    FROM AdventureWorks.Production.Product
    WHERE ProductID = ? ', 952) AT SeattleSales;
GO

Siehe auch

Verweis

@@NESTLEVEL (Transact-SQL)
DECLARE @local\_variable (Transact-SQL)
EXECUTE AS-Klausel (Transact-SQL)
REVERT (Transact-SQL)
sp_addlinkedserver (Transact-SQL)
SUSER_NAME (Transact-SQL)
sys.database_principals (Transact-SQL)
sys.server_principals (Transact-SQL)
USER_NAME (Transact-SQL)
OPENDATASOURCE (Transact-SQL)

Andere Ressourcen

osql (Dienstprogramm)
Prinzipale
sqlcmd (Dienstprogramm)
Grundlegendes zum Ausführungskontext
Grundlegendes zum Wechseln des Kontexts

Hilfe und Informationen

Informationsquellen für SQL Server 2005

Änderungsverlauf