<\/p>\n
„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.<\/b><\/p>\n
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 <\/b>(zu deutsch: gespeicherte Prozedur). <\/p>\n
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.<\/p>\n
Geschwindigkeit<\/b><\/p>\n
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. <\/p>\n
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. <\/p>\n
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.<\/p>\n
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.<\/p>\n
Geschäftslogik und Datenkonsistenz<\/p>\n
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. <\/p>\n
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. <\/p>\n
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<\/p>\n
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.<\/p>\n
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. <\/p>\n
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. <\/p>\n
Gespeicherte Prozeduren<\/b><\/p>\n
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.<\/p>\n
T-SQL bietet das Notwendigste, um Daten strukturiert zu verarbeiten. <\/p>\n
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.<\/p>\n
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<\/b> für den Besitzer dbo<\/b> angelegt werden. <\/p>\n
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 <\/b>und öffnen dort mit der rechten Maustaste auf gespeicherte Prozeduren das Kontextmenü, in dem Sie den Befehl Neue gespeicherte Prozedur <\/b>wählen (siehe Bild 1). Als Ergebnis erhalten Sie eine „Prozedurerstellungsabfrage“ mit der Vorlage für eine neue gespeicherte Prozedur.<\/p>\n
![\"pic001.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/GespeicherteProzeduren-web-images\/pic001_opt.jpeg\")
<\/p>\n
Bild 1: Eine neue gespeicherte Prozedur<\/span><\/b><\/p>\n Gespeicherte Prozeduren werden mit CREATE PROCEDURE <\/b>angelegt. Innerhalb dieser Anweisung müssen der Name der Prozedur, die Parameter und selbstverständlich auch die Anweisungen der Prozedur enthalten sein. <\/p>\n 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_<\/b> 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_<\/b> beginnen, als Systemprozeduren und sucht diese zunächst in der master<\/b>-Datenbank – und erst danach in der aktuellen Datenbank.<\/p>\n 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<\/b> die Rede. Geben Sie vorab immer das Schema dbo <\/b>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. <\/p>\n 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. <\/p>\n 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.<\/p>\n 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.<\/p>\n Mit den lokalen Variablen sind auch schon die ersten Komponenten des eigentlichen Programmcodes einer gespeicherten Prozedur angesprochen. Der Programmcode wird über die Anweisung AS <\/b>nach der Parameterdefinition eingeleitet.<\/p>\n 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<\/b>-Anweisungen oder aber – bei der Initialisierung von mehreren Variablen – in einer einzigen SELECT<\/b>-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 <\/b>werden die Variablen einzeln initialisiert, was auch einzelne Anweisungen zur Folge hat.<\/p>\n oder<\/p>\n Innerhalb des Programmcodes stehen alle Möglichkeiten von SQL zur Verfügung. Dazu kommen noch Programmsteuerungsbefehle wie BEGIN…END<\/b>, IF…ELSE<\/b>, WHILE<\/b>, BREAK<\/b>, CONTINUE<\/b>, EXECUTE<\/b>, GOTO<\/b>, PRINT<\/b>, RETURN<\/b>, WAITFOR<\/b> u.v.m.<\/p>\n Jeder zusammengehörige Block von Anweisungen wird mit einem BEGIN <\/b>und END <\/b>eingekreist. Besonders bei IF…ELSE<\/b>-Anweisungen sind diese BEGIN…END<\/b>-Blöcke immens wichtig, um die Verarbeitung mehrerer Anweisungen etwa im IF<\/b>-Part zu kennzeichnen. <\/p>\n 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<\/b>-Anweisungen innerhalb der gespeicherten Prozedur die Ergebnismengen an die aufrufende Instanz. <\/p>\n In beiden Fällen – ob Datenaufbereitung oder Datenmanipulation – wird von der gespeicherten Prozedur ein Return-Wert vom Datentyp integer <\/b>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 <\/b>bei einer fehlerfreien Ausführung und eine 1<\/b>, 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<\/b>.<\/p>\n Die Anweisung RETURN <\/b>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. <\/p>\n 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.<\/p>\n So weit ein grober Überblick zur Erstellung einer gespeicherten Prozedur. In Listing 1 sehen Sie nun die gespeicherte Prozedur dbo.spBestellungenKundeMitAnzPos<\/b>, die die Bestellungen eines Kunden abhängig von der Anzahl der Bestellpositionen auflistet.<\/p>\n Listing 1: Gespeicherte Prozedur dbo.spBestellungenKundeMitAnzPos<\/p>\n CREATE PROCEDURE [dbo].[spBestellungenKundeMitAnzPos]<\/p>\n — Kundennummer des Kunden<\/p>\n @Kundennummer nchar(5), <\/p>\n — optionale Anzahl der Positionen <\/p>\n @AnzahlPositionen int = NULL AS<\/p>\n BEGIN<\/p>\n — Verhindert detaillierte Ausgaben der einzelnen Anweisungen<\/p>\n SET NOCOUNT ON;<\/p>\n — Variable für Fehlermeldungen<\/p>\n DECLARE @strMessage As nvarchar(1000);<\/p>\n — Prüfung ob negativer Wert für Anzahl übergeben wurde<\/p>\n IF @AnzahlPositionen < 0 <\/p>\n BEGIN<\/p>\n — Meldung vorbereiten<\/p>\n SET @strMessage = €šDie Anzahl >>>€ + Cast(@AnzahlPositionen as varchar(5)) + €š<<< ist falsch.€<\/p>\n — Meldung ausgeben<\/p>\n RAISERROR (@strMessage, 16, 1)<\/p>\n — Beenden und Verlassen der Gespeicherten Prozedure mit Returnwert 1<\/p>\n RETURN 1<\/p>\n END;<\/p>\n — Prüfung, ob der Kunde in Kundentabelle existiert<\/p>\n IF NOT EXISTS (SELECT * FROM dbo.Customers WHERE CustomerId = @Kundennummer)<\/p>\n — Der Kunde existiert nicht in der Kundentabelle<\/p>\n BEGIN <\/p>\n — Meldung aufbereiten<\/p>\n SET @strMessage = €šDer Kunde >>>€ + @Kundennummer + €š<<< ist nicht vorhanden.€<\/p>\n — Meldung ausgeben<\/p>\n RAISERROR (@strMessage, 16, 1)<\/p>\n — Beenden und Verlassen der Gespeicherten Prozedure mit Returnwert 1<\/p>\n RETURN 1<\/p>\n END;<\/p>\n IF @AnzahlPositionen Is Null<\/p>\n — Es wurde keine Anzahl Positionen übergeben<\/p>\n BEGIN<\/p>\n — Ausgabe aller Bestellungen des Kunden<\/p>\n SELECT Count(*) As Anzahl, dbo.Orders.OrderId, dbo.Orders.CustomerId, dbo.Orders.OrderDate, <\/p>\n dbo.Orders.ShippedDate, Sum(Quantity*UnitPrice) As Brutto FROM dbo.Orders INNER JOIN dbo.[Order Details] <\/p>\n ON dbo.Orders.OrderId = dbo.[Order Details].OrderId WHERE dbo.Orders.CustomerId = @Kundennummer<\/p>\n GROUP BY dbo.Orders.OrderId, dbo.Orders.OrderDate, dbo.Orders.ShippedDate, dbo.Orders.CustomerId<\/p>\n ORDER BY Anzahl DESC<\/p>\n END;<\/p>\n ELSE<\/p>\n — Es wurde eine Anzahl Positionen übergeben<\/p>\n BEGIN<\/p>\n — Ausgabe der Bestellungen des Kunden mit gleich oder mehr Positionen als in Anzahl Positionen angegeben<\/p>\n SELECT Count(*) As Anzahl, dbo.Orders.OrderId, dbo.Orders.CustomerId, dbo.Orders.OrderDate, <\/p>\n dbo.Orders.ShippedDate, Sum(Quantity*UnitPrice) As Brutto FROM dbo.Orders INNER JOIN dbo.[Order Details] <\/p>\n ON dbo.Orders.OrderId = dbo.[Order Details].OrderId WHERE dbo.Orders.CustomerId = @Kundennummer<\/p>\n GROUP BY dbo.Orders.OrderId, dbo.Orders.OrderDate, dbo.Orders.ShippedDate, dbo.Orders.CustomerId<\/p>\n HAVING Count(*) >= @AnzahlPositionen ORDER BY Anzahl DESC<\/p>\n END;<\/p>\n END;<\/p>\n RETURN 0<\/p>\n <\/p>\n Die gespeicherte Prozedur zeigt einige Möglichkeiten von T-SQL. Angefangen mit der Anweisung SET NOCOUNT ON<\/b>, die vermeidet, dass nicht zu jeder SQL-Anweisung, die Daten ermittelt beziehungsweise modifiziert, eine Meldung mit xx rows affected<\/b> an den Client zurückgegeben wird. Diese sogenannten DONE_IN_PROC<\/b>-Meldungen sind in den seltensten Fällen für eine Weiterverarbeitung interessant. <\/p>\n 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 <\/p>\n Schlägt eine der Prüfungen fehl, wird eine entsprechende Meldung mit dem Wert des jeweiligen Parameters aufbereitet und in der Variablen @strMessage <\/b>gespeichert. Der Parameter @AnzahlPositionen <\/b>ist ein Integer<\/b>-Wert und muss daher mit dem Befehl CAST <\/b>in einen alphanumerischen Wert konvertiert werden, um ihn in der alphanumerischen Variablen @strMessage <\/b>speichern zu können.<\/p>\n Die aufbereitete Meldung wird per RAISERROR <\/b>ausgegeben. Meldungen per RAISERROR <\/b>werden bei der aufrufenden Instanz als Fehler interpretiert. Nach der Ausgabe der Fehlermeldung wird die gespeicherte Prozedur mit RETURN <\/b>beendet. Der Return-Wert erhält den Wert 1<\/b>, um der aufrufenden Instanz die Information mitzuteilen, dass die Prozedur nicht erfolgreich ausgeführt wurde.<\/p>\n 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<\/b>, 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<\/b>-Anweisungen ist gleichbedeutend mit der erfolgreichen Ausführung der gesamten gespeicherten Prozedur – unabhängig davon, ob die SELECT<\/b>-Anweisung Daten liefert oder nicht. Aus diesem Grund wird die gespeicherte Prozedur mit dem Return-Wert 0<\/b> beendet.<\/p>\n 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<\/b> wird mit einem Klick auf Ausführen <\/b>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.<\/p>\n Wenn Sie nach erfolgreichem Speichern der Prozedur noch weitere änderungen am Code der Prozedur vornehmen, werden Sie bei einem erneuten Klick auf Ausführen <\/b>die Meldung bekommen, dass die gespeicherte Prozedur nicht angelegt werden kann, da sie bereits vorhanden ist. Solange am Anfang Ihres Codes die Anweisung CREATE <\/b>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 <\/b>auf ALTER <\/b>ändern. Dies ist, neben dem kompletten Löschen über DROP PROCEDURE <\/b>und erneuten CREATE PROCEDURE<\/b>, der einzige Weg, den Code einer bestehenden gespeicherten Prozedur zu ändern. <\/p>\n Nachdem Sie nun die gespeicherte Prozedur mit Ausführen <\/b>im SQL Server angelegt haben, möchten Sie diese bestimmt auch ausführen. Dank des optionalen Parameters @AnzahlPositionen <\/b>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<\/p>\n liefert alle Bestellungen des Kunden ALFKI <\/b>mit zehn und mehr Bestellpositionen. Die folgende Anweisung hingegen listet sämtliche Bestellungen des Kunden ALFKI <\/b>auf:<\/p>\n 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. <\/p>\n Listing 2: Gespeicherte Prozedur <\/p>\n CREATE PROC [dbo].[spUpdateInsertRegion]<\/p>\n \n @RegionId int,<\/p>\n @RegionDescription nchar(50)<\/p>\n )<\/p>\n AS<\/p>\n BEGIN<\/p>\n SET NOCOUNT ON;<\/p>\n DECLARE @RowCount as int<\/p>\n DECLARE @Error as int<\/p>\n UPDATE dbo.Region<\/p>\n SET RegionDescription = @RegionDescription<\/p>\n WHERE RegionID = @RegionId;<\/p>\n SELECT @RowCount = @@RowCount, @Error = @@Error;<\/p>\n IF @RowCount = 0 AND @Error = 0<\/p>\n BEGIN<\/p>\n INSERT INTO dbo.Region VALUES (@RegionId, @RegionDescription)<\/p>\n SELECT @RowCount = @@RowCount, @Error = @@Error<\/p>\n END;<\/p>\n IF @RowCount = 0 AND @Error = 0<\/p>\n RETURN 0;<\/p>\n ELSE<\/p>\n RETURN 1;<\/p>\n END<\/p>\n Wurden dabei Daten geändert, wird das Insert nicht mehr benötigt. Wurden jedoch keine Daten geändert, heißt das, dass der Datensatz nicht vorhanden ist und das Insert ausgeführt werden kann.<\/p>\n Im besten Fall wird hier also nur eine Anweisung – nämlich das Update – und nicht wie bei der ursprünglichen Methode zwei Anweisungen, das Select und das Update\/Insert, ausgeführt. <\/p>\n Ob die Update-Anweisung bereits Daten gefunden und verändert hat, wird durch den Systemwert @@Rowcount <\/b>ermittelt. Diese Systemvariable – zu erkennen durch die beiden @-Zeichen – beinhaltet immer die Anzahl der Datensätze, die bei der letzten Anweisung ermittelt beziehungsweise manipuliert wurden. Wurden also Datensätze geändert, wird die Systemvariable @@Rowcount <\/b>einen Wert größer 0 <\/b>enthalten.<\/p>\n @@RowCount <\/b>enthält den Wert 0<\/b>, wenn keine Datensätze geändert wurden, was wiederum verschiedene Gründe haben kann. Entweder wurden keine Datensätze gefunden oder aber es ist beim Update ein Fehler aufgetreten. <\/p>\n Die Fehlernummer des Fehlers, der bei der zuletzt ausgeführten Anweisung innerhalb einer gespeicherten Prozedur aufgetreten ist, wird in der Systemvariablen @@Error <\/b>gespeichert. Sind nun die Werte von @@RowCount <\/b>und @@Error <\/b>gleich 0<\/b>, wurden keine Datensätze gefunden und es ist auch kein Fehler eingetreten. Ergo gibt es den Datensatz nicht und das Insert kann ausgeführt werden.<\/p>\n Da @@RowCount <\/b>und @@Error <\/b>bei jeder Anweisung in der gespeicherten Prozedur neu belegt werden, ist es erforderlich, diese Werte in eigenen Variablen zu speichern, sofern die Werte weiterverarbeitet werden sollen. Abhängig von den Werten der @@RowCount<\/b>– und @@Error<\/b>-Variablen wird die Prozedur als erfolgreich oder nicht erfolgreich beendet. Durch den Return-Wert erfährt die aufrufende Instanz, ob der Datensatz verarbeitet wurde. Um den Return-Wert auszuwerten, muss der Aufruf der gespeicherten Prozedur etwas erweitert werden:<\/p>\n Nun ist es für die Entwicklung von gespeicherten Prozeduren zwar sehr hilfreich, wenn diese im SQL Server Management Studio aufgerufen werden können, aber ein solcher manueller Aufruf bringt Sie in Ihrer Access-Applikation nicht weiter. Denn eigentlich sollen die gespeicherten Prozeduren Ihre Ergebnisse an Access übermitteln und logischerweise auch von dort aufgerufen werden.<\/p>\n Doch im Gegensatz zu Tabellen und Sichten ist das Einbinden von gespeicherten Prozeduren in Access nicht direkt möglich, sofern Sie keine Access-Projekte (ADP) verwenden – und das ist wahrscheinlich der Fall. Eine gespeicherte Prozedur kann in Access nur indirekt über eine sogenannte Pass-Through-Abfrage aufgerufen werden. <\/p>\n Pass-Through-Abfragen<\/b><\/p>\n Access bietet verschiedene Abfragetypen, wie die Auswahl- und Kreuztabellenabfrage zur Ausgabe von Daten oder die Tabellenerstellungs-, Aktualisierungs-, Lösch- und Anfügeabfrage zur Manipulation von Daten. Dazu kommen noch drei weitere Abfragen, die unter dem Begriff „SQL spezifisch“ zusammengefasst sind: UNION, Datendefinition und Pass-Through.<\/p>\n Für keine der drei letztgenannten Abfragen steht ein Abfragedesigner zur Verfügung. Diese Abfragen müssen mit SQL-Text geschrieben werden. Während bei der UNION- und der Datendefinitionsabfrage die SQL-Syntax von Access – also Jet-SQL – maßgebend ist, wird bei der Pass-Through-Abfrage die SQL-Syntax des jeweiligen Backends verwendet. Und das aus gutem Grund, denn bei einer Pass-Through-Abfrage greifen Sie direkt auf das Backend zu. Daher auch der Name dieser Abfrageart: Pass Through = Durchgriff. <\/p>\n Beim direkten Zugriff auf das Backend ist weder die Jet-Engine noch sind manipulierende Funktionen der OBDC-Schnittstelle beteiligt. Kein Access-Abfrageoptimierer greift dort ein und „optimiert“ die Abfrage, denn anhand des in der Pass-Through-Abfrage definierten Connection-Strings wird eine Verbindung zum jeweiligen Backend – in diesem Fall zum SQL Server und der entsprechenden Datenbank – aufgebaut. Über diese Verbindung wird die SQL-Anweisung direkt an Ort und Stelle ausgeführt. Und dort wird nun mal kein Jet-SQL, sondern T-SQL verstanden. <\/p>\n Für die Entwicklung einer Pass-Through-Abfrage, die auf den SQL Server zugreift, stehen Ihnen alle Möglichkeiten von T-SQL zur Verfügung: die Verwendung von benutzerdefinierten Funktionen, von weiteren gespeicherten Prozeduren, Table-Variablen, temporären Tabellen und viele mehr. Mit all diesen Möglichkeiten müssen Sie innerhalb Access aber ohne Unterstützung klarkommen, denn Access bietet Ihnen keinen Abfragedesigner oder solch moderne Entwicklungsunterstützung wie Syntax-Highlighting oder Syntax-Prüfung in Echtzeit. Daher sollten Sie Ihre SQL-Anweisungen zunächst mit dem SQL Server Management Studio entwickeln, dort testen und abschließend lediglich in die Pass-Through-Abfrage kopieren. <\/p>\n Weitaus einfacher ist es, die SQL-Anweisungen als gespeicherte Prozedur auf dem SQL Server anzulegen und diese in der Pass-Through-Abfrage aufzurufen. Natürlich können Sie auch den Code der gespeicherten Prozedur direkt in die Pass-Through-Abfrage eingeben, aber dann verschenken Sie einiges an Performance. Denken Sie an den bereits beschriebenen Prozedurcache. SQL-Anweisungen werden dort nicht immer zwischengespeichert und wiederverwendet, wohl aber gespeicherte Prozeduren. <\/p>\n Insofern sollten Sie Pass-Through-Abfragen immer in Verbindung mit einer gespeicherten Prozedur nutzen. Diese Kombination plus die Option, Parameter an gespeicherte Prozeduren zu übergeben, bieten eine Menge Möglichkeiten.<\/p>\n Um dies zu verdeutlichen, stellen Sie sich ein Einzelformular in Access vor, mit dem Sie in den Kundendaten blättern können. Über eine Kombobox können Sie einen Kunden auswählen und gezielt zum zugehörigen Datensatz navigieren. Für die Umsetzung einer solchen Anforderung gibt es in Access verschiedene Möglichkeiten. Die einfachste Methode besteht darin, die Kundentabelle als Datenherkunft für das Formular anzugeben und über den Wert der Kombobox die Datensätze zu filtern. Eine etwas aufwendigere Methode besteht darin, dass anhand des ausgewählten Werts eine SELECT<\/b>-Anweisung zusammengesetzt und diese als Datenherkunft verwendet wird. <\/p>\n Keine dieser Varianten nutzt den Geschwindigkeitsvorteil von gespeicherten Prozeduren. Genau das Gegenteil ist der Fall, denn bei der ersten Variante wird zusätzlich noch unnötiger Netzwerk-Traffic produziert. Die Umsetzung dieser Anforderung mittels einer gespeicherten Prozedur ist recht einfach: Sie erstellen auf dem SQL Server eine Prozedur, die den Datensatz zu einem bestimmten Kunden anhand eines übergebenen Parameters ermittelt. Die gespeicherte Prozedur rufen Sie über eine Pass-Through-Abfrage auf, die wiederum als Datenherkunft für das Formular verwendet wird. Der in der Kombobox ausgewählte Wert wird als Parameter an die gespeicherte Prozedur übergeben. Die ermittelt anhand des Wertes den Datensatz zum ausgewählten Kunden und gibt diesen – und nur diesen – an Access zur Ausgabe zurück.<\/p>\n Das klingt zu schön, um wahr zu sein Ist es auch! Sie können zwar an gespeicherte Prozeduren Parameter weiterleiten, aber nicht an eine Pass-Through-Abfrage. Zumindest nicht direkt. Per VBA ist es wenigstens indirekt möglich, Parameter an eine Pass-Through-Abfrage zu „übergeben“. <\/p>\n Das ist eine mehr als schmeichelhafte Umschreibung für den notwendigen Schritt, den Sie für eine solche „Parameterübergabe“ vornehmen müssen. Denn eigentlich übertragen Sie keine Parameter, sondern Sie ändern den Quellcode der Pass-Through-Abfrage vor der Ausführung dahingehend, dass Sie die bereits darin angegebenen Parameterwerte mit den neuen Werten ersetzen. Im Klartext heißt das, dass etwa der Quellcode <\/p>\n in diesen geändert wird:<\/p>\n Im Grunde genommen übergeben Sie keinen Parameter, sondern Sie erstellen zur Laufzeit eine neue Pass-Through-Abfrage – nur unter derselben Bezeichnung. Doch das ist nicht relevant. Vielmehr ist relevant, dass die darin enthaltene gespeicherte Prozedur für den SQL Server – und insbesondere für den Prozedurcache – nicht neu ist. <\/p>\n Diese Art der Parameterübergabe können Sie bei jeder Kombination von Pass-Through-Abfragen und gespeicherten Prozeduren verwenden. Egal, ob Sie diese Kombination zur Datenausgabe nutzen oder zur Datenmanipulation wie ändern, Löschen und Hinzufügen von Daten. <\/p>\n Apropos Datenmanipulation: Gerade bei Datenmanipulationen zeigt sich eine weitere Stärke dieser Kombination. Die änderung von mehreren Datensätzen – wie beispielsweise die änderung von „Germany“ in „Deutschland“ in der Spalte Country <\/b>der Tabelle dbo.Customers <\/b>– ist mit einer gespeicherten Prozedur über eine Pass-Through-Abfrage viel schlanker und wesentlich schneller erledigt als über eine Access-Aktualisierungsabfrage.<\/p>\n Bei einer Access-Aktualisierungsabfrage fordert Access zunächst alle betroffenen Datensätze vom SQL Server an. Dieser filtert die Daten nach den angegebenen Kriterien und liefert sie an Access. Für jeden Datensatz der übertragenen Datenmenge erstellt Access nun zunächst eine SELECT<\/b>-Anweisung mit einer WHERE<\/b>-Bedingung auf den Primärschlüssel des jeweiligen Datensatzes und führt diese aus. Liefert diese SELECT<\/b>-Anweisung ein Ergebnis, wird eine UPDATE<\/b>-Anweisung mit einer WHERE<\/b>-Bedingung auf den Primärschlüssel von Access erstellt und ausgeführt. Wohlgemerkt – diese beiden Abfragen werden pro Datensatz der bereits vom SQL Server gefilterten und von Access bereitgestellten Datensätze erzeugt und ausgeführt.<\/p>\n Eine Pass-Through-Abfrage mit der folgenden SQL-Anweisung hingegen wird an den SQL Server übertragen; der führt die Anweisung aus und alle betroffenen Datensätze sind auf dem aktuellen Stand:<\/p>\n UPDATE dbo.Customers SET Country = €šDeutschland€ WHERE Country = €šGermany€ <\/p>\n Pass-Through-Abfragen eignen sich also zur Datenmanipulation wie auch zur Aufbereitung von Daten. Sofern eine Pass-Through-Abfrage Daten liefert, können Sie diese wie andere Access-Abfragen mit Tabellen und Abfragen verknüpfen oder als Datenherkunft für Formulare, Berichte und Controls wie Kombo- und Listboxen nutzen. Allerdings mit einer deutlichen Einschränkung: Die Daten einer Pass-Through-Abfrage sind schreibgeschützt und können nicht geändert werden. Insofern eignen sich Pass-Through-Abfragen für schreibgeschützte Auswertungen in Formularen und natürlich besonders in Berichten. <\/p>\n Aber auch für Datenänderungen können die Daten über eine Pass-Through-Abfrage ermittelt werden. Denken Sie an das Beispiel mit der Kundenausgabe eines bestimmten Kunden. Sie können den durch eine Pass-Through-Abfrage ermittelten Datensatz in eine lokale Tabelle schreiben und diese als Datenherkunft für das Formular verwenden, mit dem Sie den Datensatz ändern. Nach der änderung lesen Sie den Datensatz aus der lokalen Tabelle und führen die änderung über eine in einer Pass-Through-Abfrage enthaltene gespeicherte Prozedur auf dem SQL Server aus. <\/p>\n Die in Access gespeicherten Pass-Through-Abfragen erkennen Sie im Access-Datenbankfenster an einem kleinen Globus. Sofern die Pass-Through-Abfrage nur der Datenmanipulation dient und keine Daten liefert, wird neben dem Globus ein Ausrufezeichen angezeigt.<\/p>\n Das war die Theorie – nun folgt der praktische Teil: Die bereits erstellte gespeicherte Prozedur dbo.spBestellungenKundeMitAnzPos<\/b> soll in eine Pass-Through-Abfrage integriert und dann ausgeführt werden.<\/p>\n Starten Sie Access, wechseln Sie dort zum Abfragefenster und klicken Sie auf Neu <\/b>um eine neue Abfrage zu erstellen. Im Menü Abfrage <\/b>wählen Sie im Untermenü SQL spezifisch <\/b>den Eintrag Pass-Through <\/b>aus (siehe Bild 3). Der Abfrageeditor ändert sich zur reinen SQL-Eingabe. Dort geben Sie folgenden Ausdruck ein:<\/p>\n Bild 2: Das Vorlageskript zu gespeicherten Prozeduren<\/span><\/b><\/p>\n Bild 3: Eine neue Pass-Through-Abfrage<\/span><\/b><\/p>\n Mit EXEC <\/b>haben Sie bereits den ersten Befehl eingegeben, der in der Syntax von Jet-SQL nicht vorkommt. Für die Ausführung dieser Anweisung auf dem SQL Server fehlt noch die entsprechende ODBC-Verbindung, in der der SQL Server und die dort befindliche Datenbank sowie die Anmeldung definiert ist.<\/p>\n Dazu wählen Sie im Menü Ansicht <\/b>den Befehl Eigenschaften<\/b>, um den gleichnamigen Dialog zu öffnen. Dort klicken Sie in der Option ODBC-Verbindung auf die Schaltfläche mit den drei Punkten, um die ODBC-Verbindung zu Ihrer Northwind-Datenbank auf Ihrem SQL Server auszuwählen beziehungsweise anzulegen. Das kann eine DSN (auf dem Rechner gespeicherte ODBC-Datenquelle) sein oder auch ein kompletter Connect-String, der den ODBC-Datenquellenadministrator überflüssig macht – eine DNSless Connection, in der Sie neben den Serverdaten auch den zu verwendenden Treibernamen samt optionaler Konfigurationsparameter angeben müssen.<\/p>\n Eine Eigenschaft der Pass-Through-Abfrage und ihre Auswirkung muss an dieser Stelle unbedingt noch erwähnt werden: Mit der Option Liefert Datensätze <\/b>legen Sie fest, ob die Pass-Through-Abfrage Datensätze an den Client zurückgibt oder ob sie Datensätze manipuliert. <\/p>\n Sofern Sie die Option Liefert Datensätze <\/b>auf Nein <\/b>setzen, wird die Pass-Through-Abfrage keine Datensätze liefern. Auch dann nicht, wenn die darin aufgerufene gespeicherte Prozedur eigentlich Daten liefert. Durch die Einstellung erwartet Access keine Daten und zeigt sie folglich auch nicht an.<\/p>\n Dafür erhalten Sie bei jeder Pass-Through-Abfrage mit der Konfiguration Liefert Datensätze <\/b>gleich Nein <\/b>vor der eigentlichen Ausführung die Warnmeldung, dass mit der Ausführung Daten geändert werden könnten. Auch wenn die in der Pass-Through-Abfrage aufgerufene gespeicherte Prozedur keine Anweisungen zur Datenänderung enthält.<\/p>\n Natürlich macht die Einstellung Liefert Datensätze <\/b>gleich Nein <\/b>nur Sinn, wenn die Pass-Through-Abfrage eine gespeicherte Prozedur enthält, die Daten manipuliert. So wie die Beispiel-Prozedur dbo.spUpdateInsertRegion<\/b>, bei der keine Datensätze angezeigt, sondern lediglich geändert werden. Insofern kann für eine solche Pass-Through-Abfrage die Option auf Nein<\/b> gesetzt werden. Sollte bei der Datenmanipulation ein Fehler auftreten, der innerhalb der gespeicherten Prozedur nicht behandelt wird, erhalten Sie auch in Access eine entsprechende Fehlermeldung. <\/p>\n Doch zurück zur Pass-Through-Abfrage mit dem Aufruf der gespeicherten Prozedur dbo.spBestellungenKundeMitAnzPos<\/b>. <\/p>\n Nachdem Sie die OBDC-Verbindung konfiguriert und die Option Liefert Datensätze <\/b>auf Ja <\/b>belassen haben, können Sie die Abfrage mit einem Klick auf Ausführen <\/b>starten. Das Ergebnis wird Ihnen wie bei einer üblichen Access-Auswahlabfrage im Datenblatt angezeigt (siehe Bild 4).<\/p>\n Bild 4: Ein erfolgreicher Durchgriff<\/span><\/b><\/p>\n Wenn Sie die Pass-Through-Abfrage nun speichern, können Sie durch einen Doppelklick auf die Abfrage immer alle Bestellungen des Kunden ALFKI mit mehr als zwei Bestellpositionen sehen. Aber bestimmt interessieren Sie auch die Bestellungen anderer Kunden.<\/p>\n Um diese zu sehen, müssen Sie lediglich die Parameterwerte der gespeicherten Prozedur ändern. Wenn Sie also beispielsweise die Bestellungen des Kunden ERNSH<\/b> mit mehr als fünf Bestellpositionen sehen möchten, müssen Sie die im Code der Pass-Through-Abfrage enthaltenen Parameter vor der Ausführung mit VBA ändern. <\/p>\n In Listing 3 sehen Sie eine solche „Parameterübergabe“ und in Listing 4 den dazu gehörenden Aufruf.<\/p>\n Listing 3: ändern der Parameter in einer Pass-Through-Abfrage<\/p>\n Public Sub subBestellungenKundeMitAnzPos(strKunde As String, _<\/p>\n Optional intAnzahl As Integer)<\/p>\n Dim ptQRY As DAO.QueryDef<\/p>\n Set ptQRY = _<\/p>\n CurrentDb.QueryDefs(„pt_spBestellungenKundeMitAnzPos“)<\/p>\n ptQRY.Connect = „ODBC;DSN=Northwind;DATABASE=Northwind;€ _<\/p>\n & €Trusted_Connection=Yes“<\/p>\n €Abfrage liefert Datensätze<\/p>\n ptQRY.ReturnsRecords = True<\/p>\n €ändern der Abfrage<\/p>\n If IsNull(intAnzahl) Then<\/p>\n €Es wurde keine Anzahl übergeben<\/p>\n ptQRY.SQL = „EXEC dbo.spBestellungenKundeMitAnzPos €“ _<\/p>\n & strKunde & „€“<\/p>\n Else<\/p>\n €Es wurde eine Anzahl übergeben<\/p>\n ptQRY.SQL = „EXEC dbo.spBestellungenKundeMitAnzPos €“ _<\/p>\n & strKunde & „€, “ & intAnzahl<\/p>\n End If<\/p>\n End Sub<\/p>\n Listing 4: Aufruf einer Pass-Through-Abfrage<\/p>\n Public Function sTestMit_ERNSTH() <\/p>\n subBestellungenKundeMitAnzPos „ERNSH“, 5<\/p>\n DoCmd.OpenQuery „pt_spBestellungenKundeMitAnzPos“<\/p>\n End Function<\/p>\n Auf diese Art und Weise können Sie jegliche Parameter von gespeicherten Prozeduren in Pass-Through-Abfragen ändern und somit die Datenherkunft von Formularen oder Berichten konkret auf die notwendigen Datensätze eingrenzen. Gerade für umfangreiche Berichte oder Formulare, in denen keine Daten geändert werden müssen, ist dies der optimale Weg. <\/p>\n Fazit<\/b><\/p>\n Gespeicherte Prozeduren sind die effizienteste Art, mit der Daten auf dem SQL Server verarbeitet werden können. Durch die Wiederverwendung bereits ausgeführter Prozeduren direkt aus dem Prozedurcache haben diese SQL Server-Objekte einen immensen Geschwindigkeitsvorteil.<\/p>\n Die Kapselung jedweder Datenänderungen beziehungsweise Datenaufbereitungen in gespeicherten Prozeduren gewährleistet nicht nur die Einhaltung von Geschäftsregeln, sondern auch die Datenkonsistenz.<\/p>\n Etwas umständlich, aber durchaus lohnend, ist der Aufruf einer gespeicherten Prozedur in Access. Dies ist nur über Pass-Through-Abfragen oder ADO-Recordsets möglich, die aber durch die Verlagerung der Ausführung von Access zum SQL Server und der damit verbundenen besseren Performance nicht unterschätzt werden sollte.<\/p>\n Der SQL Server bietet neben der gespeicherten Prozedur noch weitere Objekte an, mit denen Daten aufbereitet und manipuliert werden können: benutzerdefinierte Funktionen und Trigger.<\/p>\n Diese beiden Typen und ihre Verwendung in Access sind Inhalt des nächsten Artikels dieser Reihe.<\/p>\n Debuggen von gespeicherten Prozeduren<\/p>\n<\/td>\n<\/tr>\n Bei der Fülle von Möglichkeiten in T-SQL und in gespeicherten Prozeduren kommt natürlich automatisch die Frage „Kann man gespeicherte Prozeduren auch debuggen“. Ja – man kann. Aber nicht mit den Tools, die mit dem SQL Server geliefert werden – weder mit dem SQL Server Management Studio (SSMS) noch mit dem Business Intelligence Development Studio (BIDS). Das Debuggen von gespeicherten Prozeduren wird nur in Visual Studio 2005 unterstützt. Erst mit dem SQL Server 2008 ist das Debuggen im SSMS möglich.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\nCREATE PROCEDURE spInputOutput\r\n(\r\n@InputParameter int,\r\n@OutputParameter varchar(100) OUTPUT\r\n)\r\nAS\r\nBEGIN\r\n...<\/pre>\n
CREATE PROCEDURE spInputOutput\r\n(\r\n@InputParameter int,\r\n@OutputParameter varchar(100) OUTPUT\r\n)\r\nAS\r\nBEGIN\r\nDECLARE @Var1 int\r\nDECLARE @Var2 datetime\r\nSET @Var1 = 0\r\nSET @Var2 = getdate()\r\n...<\/pre>\n
CREATE PROCEDURE spInputOutput\r\n(\r\n@InputParameter int,\r\n@OutputParameter varchar(100) OUTPUT\r\n)\r\nAS\r\nBEGIN\r\nDECLARE @Var1 int, @Var2 datetime\r\nSELECT @Var1 = 0, @Var2 = getdate()\r\n...<\/pre>\n
...\r\nIF @Var1 > 0 THEN\r\n BEGIN\r\n SELECT @Var1\r\n RETURN 0\r\n END\r\nElse\r\n BEGIN\r\n SELECT €Fehler€\r\n RETURN 1\r\n END\r\n ...<\/pre>\n
@AnzahlPositionen <\/b>größer 0 und die übergebene Kundennummer in der Tabelle dbo.Customers <\/b>vorhanden sein.<\/pre>\n
EXEC dbo.spBestellungenKundeMitAnzPos €šALFKI€, 10<\/pre>\n
EXEC dbo.spBestellungenKundeMitAnzPos €šALFKI€<\/pre>\n
dbo.spUpdateInsertRegion<\/pre>\n
DECLARE @ReturnWert as int\r\n EXEC @ReturnWert = dbo.UpdateInsertRegion 7, €šHunsrueck€\r\n SELECT @ReturnWert As AnzahlDatensätze<\/pre>\n
EXEC dbo.SelectKunde €šALFKI€<\/pre>\n
EXEC dbo.SelectKunde €šERNH€<\/pre>\n
![\"pic002.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/GespeicherteProzeduren-web-images\/pic002_opt.jpeg\")
<\/p>\n![\"pic003.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/GespeicherteProzeduren-web-images\/pic003_opt.jpeg\")
<\/p>\n EXEC dbo.spBestellungenKundeMitAnzPos €šALFKI€, 2<\/pre>\n
![\"pic004.TIF\"](\"..\/fileadmin\/_temp_\/2008_04\/GespeicherteProzeduren-web-images\/pic004_opt.jpeg\")
<\/p>\n\n\n
\n \n \n \n <\/p>\n