Prinzipielle Frage zu Prozeduren

[Sabine Bergmann]

Eine gespeicherte Prozedur beginnt immer mit den Befehlen 'Create Prozedure...' oder 'Alter Prozedure...'. Warum?
Die Folge ist, daß ich dem ausführenden User die Rolle ddladmin und die Ausführungsrechte für die Prozedur zuweisen muß. Damit sind alle anderen Objecte (Tabellen, Views, Prozeduren,...) gefährdet. Gibt es eine Alternative?
Danke für die Lösung!

[Andreas Kosch]

Hallo,

der SQL-Standard unterscheidet zwischen DDL-Anweisungen (<i>Data Definition Language</i>) und DML-Anweisungen (<i>Data Manipulation Language</i>). Im Normalfall führt der Anwender über sein Programm nur DML-Anweisungen aus, d.h. die Datenbankobjekte (Tabellen, View, Stored Procedure, Trigger) werden vom Entwickler (oder der Entwicklungsumgebung) einmalig über DDL angelegt, <b>bevor</b> die Anwender mit dieser Datenbank arbeiten.

Der Vorteil von Stored Procedure besteht doch gerade darin, dass der Anwender nur das EXECUTE-Recht für diese Stored Procedure benötigt, aber keine Rechte für die Tabellen, auf die diese Stored Procedure zugreift.

Wenn allerdings der Benutzer im Kontext seiner Datenbank-Sessions in der Lage sein soll, selbst neue Datenbankobjekte anzulegen, benötigt er in jedem Fall die dazu notwendigen Datenbank-Rechte

[Sabine Bergmann]

Danke, Herr Kosch, für die prompte Antwort am frühen Morgen! Ihre Darstellung ist gut verständlich und nachvollziehbar. Nur hatte ich die Frage ein klein wenig anders gemeint: Die Anweisung "Create Prozedure" impliziert einen DDL-Vorgang:"Erstelle eine Prozedur" in der Datenabank. Nach meiner Erfahrung MUSS ich dazu dem User über das Execute-Recht der Prozedur hinaus auch DDL-Rechte geben. Lieber würde ich in der Prozedur NUR den Select-Befehl usw.unterbringen. Die Erstellung (Create...) möchte ich ich als Entwickler VOR dem ersten User-Zugriff übernehmen, so wie Sie das beschrieben haben. Meine Frage war, ob und wie das geht (also die Trennung zwischen Create und Execute des Select, bzw. eine geschicktere Rechtevergabe

[Andreas Kosch]

Hallo,

die Trennung zwischen dem Anlegen und dem Aufrufen einer Stored Procedure ist doch der Regelfall. Das folgende Beispiel verdeutlicht das Prinzip - diese Mini-SQL-Script legt eine neue Datenbank an, erzeugt die Tabelle und die Stored Procedure, richtet einen neuen Datenbankbenutzer ein und vergibt das Execute-Recht für die Stored Procedure:
<pre>
<b>CREATE</b> <b>DATABASE</b> TestDB
<b>GO</b>
<br>
<b>USE</b> TestDB
<b>GO</b>
<br>
<b>CREATE</b> <b>TABLE</b> TestTbl
(
rec_id <b>INTEGER</b> <b>NOT</b> <b>NULL</b> <b>PRIMARY</b> <b>KEY</b>,
wert <b>VARCHAR</b>(255) <b>NULL</b>
)
<b>GO</b>
<br>
<b>CREATE</b> <b>PROCEDURE</b> spSelectTestTbl
(
@rec_id <b>INTEGER</b>
)
<b>AS</b>
<b>SELECT</b> wert
<b>FROM</b> dbo.TestTbl
<b>WHERE</b> rec_id = @rec_id
<b>RETURN</b> @@ROWCOUNT
<b>GO</b>
<br>
sp_addlogin <font color="#9933CC">'NewDBUser'</font>, <font color="#9933CC">'userpasswd'</font>, <font color="#9933CC">'TestDB'</font>
<b>GO</b>
<br>
sp_grantdbaccess <font color="#9933CC">'NewDBUser'</font>
<b>GO</b>
<br>
<b>grant</b> <b>execute</b> <b>on</b> dbo.spSelectTestTblt <b>to</b> NewDBUser
<b>GO</b>
</pre>
Der Anwender kann nun die Stored Procedure aufrufen, ohne dass er Rechte an der Tabelle erhält