“Oh – by the way: The same procedure as last year, Miss Sophie” “The same procedure as every year, James.” Auch der SQL Server bietet Procedures: Stored Procedures. Und wie auch Miss Sophie greift der SQL Server gerne auf altbewährte Procedures zurück – natürlich weitaus öfter als nur einmal im Jahr und auch nicht immer nur auf ein und dieselbe Weise. Im Gegenteil: Sie können für die Verwaltung und Aufbereitung Ihrer Daten mehrere Stored Procedures in Ihrer Datenbank anlegen und diese immer wieder verwenden. Das sollten Sie auch ausgiebig tun, denn gerade Stored Procedures bieten das meiste Potenzial, wenn es um Geschwindigkeit, Datenkonsistenz und die Implementation von Geschäftslogik geht.
Eine Stored Procedure ist nichts anderes als eine Prozedur, in der, ähnlich einer VBA-Funktion, mehrere Anweisungen – hier natürlich SQL-Anweisungen – gespeichert werden. Daher auch der Name Stored Procedure (zu deutsch: gespeicherte Prozedur).
Warum aber sollten SQL-Anweisungen auf dem SQL Server gespeichert werden Immerhin können die SQL-Anweisungen doch im Frontend wunderbar nach den dort gegebenen Umständen zur Laufzeit zusammengestellt und ausgeführt werden. Die Antwort auf diese Frage lautet: Geschwindigkeit.
Geschwindigkeit
Bevor der SQL Server eine SQL-Anweisung ausführt, prüft er zunächst die Syntax der SQL-Anweisung. Zu dieser Syntaxprüfung gehört nicht nur die Kontrolle der Syntax der einzelnen Befehle, sondern es wird auch die Existenz der dort angegebenen SQL Server-Objekte, wie Tabellen, Sichten und deren Spalten, geprüft. Diese Syntaxprüfung erfolgt vor jeder Ausführung der SQL-Anweisung.
Nach der Syntaxkontrolle wird die SQL-Anweisung zunächst kompiliert, das heißt, es wird ein Ausführungsplan für die Ermittlung der Daten durch den Abfrageoptimierer erstellt. Dieser Ausführungsplan ist mit einer Wegbeschreibung vergleichbar. Er enthält die Reihenfolge, in der etwa die Tabellen der SQL-Anweisung gelesen oder welche Indizes benutzt werden. Anhand dieses Ausführungsplans wird die SQL-Anweisung ausgeführt.
Auch bei der Ausführung einer gespeicherten Prozedur wird zunächst eine Syntaxkontrolle durchgeführt und ein Ausführungsplan erstellt. Doch im Gegensatz zur SQL-Anweisung nicht bei jeder, sondern nur bei der ersten Ausführung. Denn der Ausführungsplan wird im sogenannten Prozedurcache – also im Arbeitsspeicher – abgelegt. Bei der nächsten Ausführung entfallen Syntaxkontrolle und Kompilieren der gespeicherten Prozedur. Der SQL Server greift direkt auf den Ausführungsplan im Arbeitsspeicher zu. Und das macht die Ausführung von gespeicherten Prozeduren schnell – sehr schnell.
Aber nicht nur die Geschwindigkeit ist ein Trumpf der gespeicherten Prozeduren. Mit gespeicherten Prozeduren können Sie auch die Datenkonsistenz und das Einhalten von Geschäftsregeln gewährleisten.
Geschäftslogik und Datenkonsistenz
Durch die Möglichkeit, mehrere SQL-Anweisungen – ob SELECT, UPDATE, INSERT oder DELETE – in einer gespeicherten Prozedur zu hinterlegen, sind diese prädestiniert für die Umsetzung der Geschäftslogik auf dem SQL Server.
Der Vorteil liegt auf der Hand – oder besser gesagt auf dem SQL Server: Egal mit welchem Frontend die Daten der Datenbank verwaltet oder ausgewertet werden, sofern die Verarbeitung über gespeicherte Prozeduren stattfindet, werden immer dieselben Algorithmen beziehungsweise Regeln für die Auswertungen oder Datenmanipulationen verwendet. An diesen Regeln gibt es kein Vorbei.
Natürlich gibt es gewitzte Benutzer, die durchaus in der Lage sind, die Daten einer Tabelle über eine ODBC- oder OLEDB-Verbindung zu lesen oder gar zu ändern. Doch auch dies kann mit gespeicherten Prozeduren verhindert werden. Hier kommt das Rechtekonzept des SQL Servers ins Spiel: Sie nehmen den Benutzern jegliche Rechte an den Tabellen. Die Benutzer dürfen die Daten einer Tabelle weder lesen, ändern oder löschen noch neue Datensätze hinzufügen. Diese Aktionen sind nur über entsprechende gespeicherte Prozeduren möglich, für deren Ausführung die Benutzer die notwendigen Rechte haben. Eine Datenmanipulation direkt in den Tabellen über eine x-beliebige ODBC- oder OLEDB-Schnittstelle ist mit diesem Konzept nicht mehr möglich. Vielmehr können die Daten nur über die in den gespeicherten Prozeduren hinterlegten Regeln und Algorithmen der Geschäftslogik verändert und ausgewertet werden. Können Sie sich eine bessere Methode zur Gewährleistung der Datenkonsistenz vorstellen
Nun sind Geschäftsregeln nicht gerade ein Fels in der Brandung im “Daily Business”. Geschäftsregeln werden ständig modernisiert, verbessert und neuen Gegebenheiten angepasst. Das bedeutet ständige Anpassungen von bestehender Programmlogik beziehungsweise von Programmcode. Sofern Sie die Regeln und Algorithmen zur Datenaufbereitung beziehungsweise Datenverarbeitung in gespeicherten Prozeduren gekapselt haben, müssen Sie nicht zig Frontends an die neuen Regeln anpassen, sondern lediglich die betroffenen gespeicherten Prozeduren. Das Frontend bleibt von solchen änderungen weitgehend unberührt. Lediglich bei änderungen in der Parameterübergabe einer gespeicherten Prozedur muss diese im Frontend angepasst werden.
Dasselbe gilt für eine nachträgliche änderung des Datenbankdesigns – was bei einer Datenbankentwicklung natürlich nie vorkommt. Falls dieser seltene Fall doch mal eintreten sollte, müssen nur die gespeicherten Prozeduren angepasst werden, die die Daten der betroffenen Tabellen auswerten beziehungsweise verwalten.
Sie sehen, mit gespeicherten Prozeduren haben Sie nicht nur Geschwindigkeitsvorteile, sondern auch eine gesunde Datenkonsistenz. Um jetzt noch in den Genuss von schnellen und stringenten gespeicherten Prozeduren zu kommen, müssen Sie nur eines tun: Sie müssen die gespeicherten Prozeduren schreiben.
Gespeicherte Prozeduren
Gespeicherte Prozeduren werden in T-SQL geschrieben. Diese Sprache ist die “Programmier”-Sprache des SQL Servers. Programmier-Sprache ist eigentlich etwas zu hoch gegriffen, denn T-SQL ist doch sehr spartanisch, was seine Möglichkeiten betrifft. Für Datenauswertungen beziehungsweise -manipulationen jedoch ist T-SQL absolut ausreichend und – bei aller Diskussion über Möglichkeiten, .NET innerhalb von gespeicherten Prozeduren verwenden zu können – auch weiterhin die schnellste Variante, Daten auf dem SQL Server zu verarbeiten. Und es kommen mit jeder neuen SQL Server-Version neue T-SQL-Befehle dazu.
T-SQL bietet das Notwendigste, um Daten strukturiert zu verarbeiten.
- Sie können Eingabe- und Ausgabeparameter mit und ohne Standardwerte definieren.
- Sie können Variablen deklarieren und nutzen.
- Sie können Systemwerte abfragen, wie die Anzahl der geänderten Datensätze, Fehler usw.
- Sie können IF…ELSE-Anweisungen durchführen.
- Sie können Schleifen programmieren – was Sie bitte nur dann tun, wenn es nicht anders geht.
- Sie können Zwischenergebnisse in temporären Tabellen beziehungsweise in Table-Variablen speichern.
- Sie können gespeicherte Prozeduren innerhalb von gespeicherten Prozeduren aufrufen.
- Sie können Sichten und benutzerdefinierte Funktionen verwenden.
- Und last but not least ist es natürlich auch möglich, mit T-SQL Prozeduren zu schreiben, deren Ausführung eher langsam als schnell ist.
Der letzte Punkt ist durchaus ernst zu nehmen. Wie bei jeder Programmiersprache sollte der Programmierer auch bei T-SQL wissen, was er tut. Auch hier ist es sehr einfach, einen schlechten und aufgeblähten Code zu schreiben, der lange Verarbeitungszeiten und hohen CPU-Verbrauch produziert.
Doch genug der Theorie. Anhand eines Beispiels werden Sie nun sehen, wie eine gespeicherte Prozedur angelegt wird. In der Northwind-Datenbank soll eine gespeicherte Prozedur namens spBestellungenKundeMitAnzPos für den Besitzer dbo angelegt werden.
Dazu müssen Sie zunächst das SQL Server Management Studio öffnen und dort zur Northwind-Datenbank wechseln. Innerhalb der Datenbank erweitern Sie den Zweig Programmierbarkeit und öffnen dort mit der rechten Maustaste auf gespeicherte Prozeduren das Kontextmenü, in dem Sie den Befehl Neue gespeicherte Prozedur wählen (siehe Bild 1). Als Ergebnis erhalten Sie eine “Prozedurerstellungsabfrage” mit der Vorlage für eine neue gespeicherte Prozedur.
Bild 1: Eine neue gespeicherte Prozedur
Gespeicherte Prozeduren werden mit CREATE PROCEDURE angelegt. Innerhalb dieser Anweisung müssen der Name der Prozedur, die Parameter und selbstverständlich auch die Anweisungen der Prozedur enthalten sein.
Der Name der gespeicherten Prozedur darf keine Leerzeichen oder eckigen Klammern enthalten, wohingegen Unterstriche erlaubt sind. Jedoch steckt in der Verwendung von Unterstrichen eine kleine Performancefalle. Ihre gespeicherten Prozeduren sollten nicht mit sp_ beginnen. Dieses Präfix ist für die systemeigenen Prozeduren des SQL Servers vorgesehen. Es hindert Sie allerdings nichts und niemand daran, dieses Präfix zu nutzen. Sie erhalten auch keine Fehlermeldung. Aber der SQL Server interpretiert gespeicherte Prozeduren, die mit sp_ beginnen, als Systemprozeduren und sucht diese zunächst in der master-Datenbank – und erst danach in der aktuellen Datenbank.
Zum Namen gehört auch der Bezeichner des Schemas. Über das Schema eines Objekts werden unter anderem die Zugriffsrechte verwaltet. Es würde jedoch den Rahmen dieses Artikels sprengen, detailliert auf die Schemata einzugehen. Um es an dieser Stelle so kurz wie möglich zu halten: Hier ist von dem Zusatz dbo die Rede. Geben Sie vorab immer das Schema dbo bei der Erstellung von SQL Server-Objekten an, um eine einheitliche Basis für die Weiterentwicklung und für eine spätere Konfiguration eines Berechtigungskonzepts zu haben.
Nach der Namensgebung folgt die Definition der Parameter. Ein Parameter wird hinter dem Namen der Prozedur in Klammern definiert. Mehrere Parameter werden dabei durch Komma getrennt. Eine Prozedur muss keine, kann aber bis zu 1.024 Parameter enthalten. Jeder einzelne Parameter ist mit Namen, Datentyp und Richtung und ggf. mit einem Standardwert zu definieren.
Die Richtung zeigt den Weg des Parameters. Es gibt Input- wie auch Output-Parameter. OUTPUT-Parameter werden mit der Erweiterung OUTPUT gekennzeichnet und geben einen Wert aus der gespeicherten Prozedur an die aufrufende Instanz zurück.
CREATE PROCEDURE spInputOutput ( @InputParameter int, @OutputParameter varchar(100) OUTPUT ) AS BEGIN ...
Die Datentypen der Parameter entsprechen den Datentypen, die auch bei Tabellen verwendet werden. Jeder Parameter muss mit einem @-Zeichen beginnen. Dies gilt auch für jede lokale Variable, die innerhalb der gespeicherten Prozedur genutzt wird.
Mit den lokalen Variablen sind auch schon die ersten Komponenten des eigentlichen Programmcodes einer gespeicherten Prozedur angesprochen. Der Programmcode wird über die Anweisung AS nach der Parameterdefinition eingeleitet.
Lokale Variablen werden in derselben Art wie die Parameter deklariert – mit der Ausnahme, dass bei der Deklaration nicht direkt ein Wert zugewiesen werden kann. Dies ist erst seit SQL Server 2008 möglich. Eine Initialisierung können Sie entweder in einzelnen SET-Anweisungen oder aber – bei der Initialisierung von mehreren Variablen – in einer einzigen SELECT-Anweisung durchführen. Letzteres ist die effektivere Methode, da hier für die Initialisierung der einzelnen Variablen nur eine einzige Anweisung ausgeführt wird. Bei SET werden die Variablen einzeln initialisiert, was auch einzelne Anweisungen zur Folge hat.
CREATE PROCEDURE spInputOutput ( @InputParameter int, @OutputParameter varchar(100) OUTPUT ) AS BEGIN DECLARE @Var1 int DECLARE @Var2 datetime SET @Var1 = 0 SET @Var2 = getdate() ...
oder
CREATE PROCEDURE spInputOutput ( @InputParameter int, @OutputParameter varchar(100) OUTPUT ) AS BEGIN DECLARE @Var1 int, @Var2 datetime SELECT @Var1 = 0, @Var2 = getdate() ...
Innerhalb des Programmcodes stehen alle Möglichkeiten von SQL zur Verfügung. Dazu kommen noch Programmsteuerungsbefehle wie BEGIN…END, IF…ELSE, WHILE, BREAK, CONTINUE, EXECUTE, GOTO, PRINT, RETURN, WAITFOR u.v.m.
Jeder zusammengehörige Block von Anweisungen wird mit einem BEGIN und END eingekreist. Besonders bei IF…ELSE-Anweisungen sind diese BEGIN…END-Blöcke immens wichtig, um die Verarbeitung mehrerer Anweisungen etwa im IF-Part zu kennzeichnen.
...
IF @Var1 > 0 THEN
BEGIN
SELECT @Var1
RETURN 0
END
Else
BEGIN
SELECT €Fehler€
RETURN 1
END
...
Das Ergebnis der Prozedur wird abhängig von ihrer Art und Aufgabe zurückgegeben. Gespeicherte Prozeduren können zur Datenmanipulation, aber auch zur Datenaufbereitung verwendet werden. Bei der Datenaufbereitung liefern die jeweiligen SELECT-Anweisungen innerhalb der gespeicherten Prozedur die Ergebnismengen an die aufrufende Instanz.
In beiden Fällen – ob Datenaufbereitung oder Datenmanipulation – wird von der gespeicherten Prozedur ein Return-Wert vom Datentyp integer an die aufrufende Instanz zurückgegeben. Dieser Wert kann als Kennzeichnung, ob die gespeicherte Prozedur erfolgreich ausgeführt wurde oder ein Fehler eingetreten ist, weiterverwendet werden. Die Systemprozeduren des SQL Servers liefern eine 0 bei einer fehlerfreien Ausführung und eine 1, wenn die Anweisung mit einem Fehler beendet wurde. Diese Vorgehensweise ist nicht zwingend vorgeschrieben, aber empfehlenswert. Den Return-Wert übergeben Sie mit der Anweisung RETURN.
Die Anweisung RETURN ist immer die letzte Anweisung, die in einer gespeicherten Prozedur ausgeführt wird. Sie können diese Anweisung mehrfach an beliebigen Stellen in einer gespeicherten Prozedur angeben. Sobald aber die Anweisung das erste Mal ausgeführt wird, ist die gespeicherte Prozedur beendet. Der nachfolgende Code wird nicht mehr ausgeführt.
Jede Anweisung beziehungsweise jeder zusammengehörende Anweisungsblock innerhalb einer gespeicherten Prozedur sollte mit einem Semikolon abgeschlossen werden. Das Semikolon ist für die SQL Server-Versionen bis einschließlich SQL Server 2005 nicht zwingend erforderlich. Ab SQL Server 2008 aber ist ein Semikolon ein syntaktisches Muss. Je früher Sie sich also an das Semikolon gewöhnen, desto weniger sind Sie ab der Version 2008 auf Fehlersuche.
So weit ein grober Überblick zur Erstellung einer gespeicherten Prozedur. In Listing 1 sehen Sie nun die gespeicherte Prozedur dbo.spBestellungenKundeMitAnzPos, die die Bestellungen eines Kunden abhängig von der Anzahl der Bestellpositionen auflistet.
Listing 1: Gespeicherte Prozedur dbo.spBestellungenKundeMitAnzPos
CREATE PROCEDURE [dbo].[spBestellungenKundeMitAnzPos]
— Kundennummer des Kunden
@Kundennummer nchar(5),
— optionale Anzahl der Positionen
@AnzahlPositionen int = NULL AS
BEGIN
— Verhindert detaillierte Ausgaben der einzelnen Anweisungen
SET NOCOUNT ON;
— Variable für Fehlermeldungen
DECLARE @strMessage As nvarchar(1000);
— Prüfung ob negativer Wert für Anzahl übergeben wurde
IF @AnzahlPositionen < 0
BEGIN
— Meldung vorbereiten
SET @strMessage = €šDie Anzahl >>>€ + Cast(@AnzahlPositionen as varchar(5)) + €š<<< ist falsch.€
— Meldung ausgeben
RAISERROR (@strMessage, 16, 1)
— Beenden und Verlassen der Gespeicherten Prozedure mit Returnwert 1
RETURN 1
END;
— Prüfung, ob der Kunde in Kundentabelle existiert
IF NOT EXISTS (SELECT * FROM dbo.Customers WHERE CustomerId = @Kundennummer)
— Der Kunde existiert nicht in der Kundentabelle
BEGIN
— Meldung aufbereiten
SET @strMessage = €šDer Kunde >>>€ + @Kundennummer + €š<<< ist nicht vorhanden.€
— Meldung ausgeben
RAISERROR (@strMessage, 16, 1)
— Beenden und Verlassen der Gespeicherten Prozedure mit Returnwert 1
RETURN 1
END;
IF @AnzahlPositionen Is Null
— Es wurde keine Anzahl Positionen übergeben
BEGIN
— Ausgabe aller Bestellungen des Kunden
SELECT Count(*) As Anzahl, dbo.Orders.OrderId, dbo.Orders.CustomerId, dbo.Orders.OrderDate,
dbo.Orders.ShippedDate, Sum(Quantity*UnitPrice) As Brutto FROM dbo.Orders INNER JOIN dbo.[Order Details]
ON dbo.Orders.OrderId = dbo.[Order Details].OrderId WHERE dbo.Orders.CustomerId = @Kundennummer
GROUP BY dbo.Orders.OrderId, dbo.Orders.OrderDate, dbo.Orders.ShippedDate, dbo.Orders.CustomerId
ORDER BY Anzahl DESC
END;
ELSE
— Es wurde eine Anzahl Positionen übergeben
BEGIN
— Ausgabe der Bestellungen des Kunden mit gleich oder mehr Positionen als in Anzahl Positionen angegeben
SELECT Count(*) As Anzahl, dbo.Orders.OrderId, dbo.Orders.CustomerId, dbo.Orders.OrderDate,
dbo.Orders.ShippedDate, Sum(Quantity*UnitPrice) As Brutto FROM dbo.Orders INNER JOIN dbo.[Order Details]
ON dbo.Orders.OrderId = dbo.[Order Details].OrderId WHERE dbo.Orders.CustomerId = @Kundennummer
GROUP BY dbo.Orders.OrderId, dbo.Orders.OrderDate, dbo.Orders.ShippedDate, dbo.Orders.CustomerId
HAVING Count(*) >= @AnzahlPositionen ORDER BY Anzahl DESC
END;
END;
RETURN 0
Die gespeicherte Prozedur zeigt einige Möglichkeiten von T-SQL. Angefangen mit der Anweisung SET NOCOUNT ON, die vermeidet, dass nicht zu jeder SQL-Anweisung, die Daten ermittelt beziehungsweise modifiziert, eine Meldung mit xx rows affected an den Client zurückgegeben wird. Diese sogenannten DONE_IN_PROC-Meldungen sind in den seltensten Fällen für eine Weiterverarbeitung interessant.
Nach dieser eher technischen Anweisung geht es nun an die Programmlogik der gespeicherten Prozedur. Als Erstes werden die Eingaben der Parameter geprüft. Dabei muss der Wert des Parameters
@AnzahlPositionen größer 0 und die übergebene Kundennummer in der Tabelle dbo.Customers vorhanden sein.
Schlägt eine der Prüfungen fehl, wird eine entsprechende Meldung mit dem Wert des jeweiligen Parameters aufbereitet und in der Variablen @strMessage gespeichert. Der Parameter @AnzahlPositionen ist ein Integer-Wert und muss daher mit dem Befehl CAST in einen alphanumerischen Wert konvertiert werden, um ihn in der alphanumerischen Variablen @strMessage speichern zu können.
Die aufbereitete Meldung wird per RAISERROR ausgegeben. Meldungen per RAISERROR werden bei der aufrufenden Instanz als Fehler interpretiert. Nach der Ausgabe der Fehlermeldung wird die gespeicherte Prozedur mit RETURN beendet. Der Return-Wert erhält den Wert 1, um der aufrufenden Instanz die Information mitzuteilen, dass die Prozedur nicht erfolgreich ausgeführt wurde.
Sofern beide Prüfungen ein positives Ergebnis liefern, wird die Verarbeitung fortgesetzt. Maßgebend für die weitere Verarbeitung ist der Wert des Parameters @AnzahlPositionen, anhand dessen die Bestellungen eines Kunden ermittelt werden. Der Wert stellt dabei die Mindestanzahl der Positionen einer Bestellung dar. Enthält der Parameter einen Wert, werden die Bestellungen des Kunden nach diesem Wert gefiltert; enthält der Parameter keinen Wert, werden alle Bestellungen des Kunden ausgegeben. Die Ausführung einer der beiden SELECT-Anweisungen ist gleichbedeutend mit der erfolgreichen Ausführung der gesamten gespeicherten Prozedur – unabhängig davon, ob die SELECT-Anweisung Daten liefert oder nicht. Aus diesem Grund wird die gespeicherte Prozedur mit dem Return-Wert 0 beendet.
Diese kleine gespeicherte Prozedur zeigt nur einige wenige Möglichkeiten von T-SQL. Es gibt natürlich noch einiges mehr im Bereich der T-SQL-Programmierung, was aber den Rahmen dieses Artikels sprengen würde. Die gespeicherte Prozedur dbo.spBestellungenKundeMitAnzPos wird mit einem Klick auf Ausführen im SQL Server gespeichert – sofern der Code keinen syntaktischen Fehler enthält. Sollten noch Fehler im Code sein, erhalten Sie im unteren Bereich des Codefensters eine Fehlermeldung, die mehr oder weniger aussagekräftig auf den Syntaxfehler hinweist. Mit einem Doppelklick auf die Fehlermeldung können Sie direkt zur fehlerhaften Zeile springen und diese korrigieren.
Wenn Sie nach erfolgreichem Speichern der Prozedur noch weitere änderungen am Code der Prozedur vornehmen, werden Sie bei einem erneuten Klick auf Ausführen die Meldung bekommen, dass die gespeicherte Prozedur nicht angelegt werden kann, da sie bereits vorhanden ist. Solange am Anfang Ihres Codes die Anweisung CREATE steht, wird der SQL Server versuchen, den Code im Abfragefenster als neue gespeicherte Prozedur anzulegen. Um nachträgliche Code-änderungen speichern zu können, müssen Sie den Befehl von CREATE auf ALTER ändern. Dies ist, neben dem kompletten Löschen über DROP PROCEDURE und erneuten CREATE PROCEDURE, der einzige Weg, den Code einer bestehenden gespeicherten Prozedur zu ändern.
Nachdem Sie nun die gespeicherte Prozedur mit Ausführen im SQL Server angelegt haben, möchten Sie diese bestimmt auch ausführen. Dank des optionalen Parameters @AnzahlPositionen lässt sich die neue gespeicherte Prozedur in zwei Varianten aufrufen. Entweder mit der Anzahl der Bestellpositionen, die die Bestellungen mindestens enthalten müssen, oder mit allen Bestellungen des angegebenen Kunden. Die Anweisung
EXEC dbo.spBestellungenKundeMitAnzPos €šALFKI€, 10
liefert alle Bestellungen des Kunden ALFKI mit zehn und mehr Bestellpositionen. Die folgende Anweisung hingegen listet sämtliche Bestellungen des Kunden ALFKI auf:
EXEC dbo.spBestellungenKundeMitAnzPos €šALFKI€
Ergänzend zum Beispiel der Datenaufbereitung in Listing 1 zeigt Listing 2 noch eine kleine gespeicherte Prozedur, mit der die Daten einer Tabelle modifiziert werden. Die Anforderung besteht darin, dass ein Datensatz abhängig davon, ob er bereits existiert, geändert oder angelegt werden soll. Auch wenn es auf den ersten Blick etwas dreist aussieht, aber auf diese Art und Weise wird die Aufgabe “Update oder Insert” am effektivsten gelöst. Anstatt erst mit einer eigenen SELECT-Anweisung zu prüfen, ob der Datensatz bereits vorhanden ist, und anhand des Ergebnisses ein Update oder ein Insert auszuführen, wird hier grundsätzlich erst ein Update ausgeführt.
Listing 2: Gespeicherte Prozedur
dbo.spUpdateInsertRegion
CREATE PROC [dbo].[spUpdateInsertRegion]
@RegionId int,
@RegionDescription nchar(50)
)
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo