Wer Daten zwischen einer Access-Anwendung und einem SQL Server austauscht, landet früher oder später bei gespeicherten Prozeduren. Sie kapseln die Datenbanklogik serverseitig, liefern bessere Performance als dynamisch zusammengebautes SQL und lassen sich sauber rechtebasiert absichern. Der Aufruf per ADODB erfordert allerdings jedes Mal eine ganze Reihe gleicher Schritte: Verbindung öffnen, Command<\/b>-Objekt erzeugen, CommandType<\/b> setzen, Parameter definieren, Werte zuweisen, Prozedur ausführen, Ergebnis auslesen. Schreibt man das für jede Prozedur neu, wächst der Code schnell zu unübersichtlichen Ausmaßen an. In diesem Artikel bauen wir ein kleines Wrapper-Modul, das diese Arbeit einmalig erledigt. Anschließend kannst Du jede gespeicherte Prozedur mit einer einzigen Zeile Code aufrufen – inklusive Parameterübergabe und Rückgabewert. Als praktisches Beispiel binden wir den Wrapper an ein vollständiges Mitarbeiter-Formular mit allen vier CRUD-Operationen an.<\/b><\/p>\n
Beispieldatenbank<\/h2>\n
Die Beispiele dieses Artikels findest Du in der Beispieldatenbank ADODB_GespeicherteProzeduren.accdb<\/b>. Die zugehörige SQL Server-Datenbank heißt Test_GespeicherteProzeduren<\/b> und enthält die beiden Tabellen tblAbteilung<\/b> und tblMitarbeiter<\/b>. Das Skript zum Anlegen der Tabellen, der Testdaten und der gespeicherten Prozeduren findest Du im Modul mdlSQLServerDB<\/b> als auskommentierten T-SQL-Code, den Du direkt in ein Abfragefenster des SQL Server Management Studio kopieren kannst.<\/p>\nDie vier gespeicherten Prozeduren<\/h2>\n
Für die Tabelle tblMitarbeiter<\/b> stehen vier gespeicherte Prozeduren bereit, die sich an den vier klassischen CRUD-Operationen orientieren: SELECT<\/b>, INSERT<\/b>, UPDATE <\/b>und DELETE<\/b>. Schauen wir uns diese kurz der Reihe nach an, damit wir wissen, welche Parameter unser Wrapper später bedienen muss.<\/p>\n
Die Prozedur spMitarbeiterSelectNachMitarbeiterID<\/b> liefert entweder alle Mitarbeiter zurück oder nur den Mitarbeiter mit einer bestimmten ID, abhängig davon, ob der optionale Parameter @MitarbeiterID<\/b> übergeben wird (siehe Listing 1).<\/p>\n Listing 1: Gespeicherte Prozedur zum Auslesen der Mitarbeiter<\/span><\/b><\/p>\n Die Prozedur spMitarbeiterInsert<\/b> legt einen neuen Mitarbeiter an und liefert die neu vergebene MitarbeiterID<\/b> über den Output-Parameter @IDNEW<\/b> zurück. Wir verwenden dafür die Funktion SCOPE_IDENTITY<\/b>, die den zuletzt in der aktuellen Sitzung und im aktuellen Gültigkeitsbereich erzeugten Autowert liefert (siehe Listing 2).<\/p>\n Listing 2: Gespeicherte Prozedur zum Anlegen eines Mitarbeiters<\/span><\/b><\/p>\n Die Prozedur spMitarbeiterUpdate<\/b> aktualisiert einen bestehenden Datensatz und liefert über @RowsAffected<\/b> zurück, wie viele Datensätze betroffen waren (siehe Listing 3).<\/p>\n Listing 3: Gespeicherte Prozedur zum Aktualsiieren eines Mitarbeiters<\/span><\/b><\/p>\n Die Prozedur spMitarbeiterDelete<\/b> schließlich löscht einen Datensatz und liefert ebenfalls @RowsAffected<\/b> zurück. Den Wert für @@ROWCOUNT<\/b> greifen wir in beiden Fällen direkt im Anschluss an die UPDATE<\/b>– beziehungsweise DELETE<\/b>-Anweisung ab, bevor eine andere Anweisung diesen Wert überschreibt (siehe Listing 4).<\/p>\n Listing 4: Gespeicherte Prozedur zum Löschen eines Mitarbeiters<\/span><\/b><\/p>\n Der direkte Aufruf einer gespeicherten Prozedur per ADODB sieht üblicherweise so aus: Du erzeugst ein Connection<\/b>-Objekt, öffnest es mit einer Verbindungszeichenfolge, erzeugst ein Command<\/b>-Objekt, weist diesem die Verbindung zu, setzt den Namen der Prozedur als CommandText<\/b> und den CommandType<\/b> auf adCmdStoredProc<\/b>. Danach legst Du per CreateParameter<\/b> jeden einzelnen Parameter an, weist ihm einen Wert zu und hängst ihn an die Parameters<\/b>-Auflistung des Command<\/b>-Objekts an. Erst dann kannst Du Execute<\/b> aufrufen.<\/p>\n Wie das im Einzelnen aussieht, haben wir bereits im Artikel ADODB: Gespeicherte Prozeduren ausführen<\/b>(www.vbentwickler.de\/ 503<\/b>) beschrieben.<\/p>\n Macht man das für vier Prozeduren, vervierfacht sich dieser Code. Macht man es für 40 Prozeduren, hat man sehr viel Schreibarbeit und sehr viele Stellen, an denen Tippfehler passieren können. Ein Wrapper-Modul erledigt diese immer gleiche Arbeit genau einmal und stellt den Aufruf als kurze Funktion zur Verfügung. Der Aufruf einer Prozedur sieht damit so aus:<\/p>\n Eine Zeile – und Du erhältst das Recordset für den Mitarbeiter mit der ID 5<\/b>. Das ist das Ziel.<\/p>\n Den ganzen Code unseres Wrappers packen wir in das Modul mdlADODB_Parameter<\/b>. Als Erstes definieren wir oben im Modul einige Konstanten mit den Verbindungsdaten. Diese legen wir als Private Const<\/b> an, damit sie nur innerhalb des Moduls sichtbar sind. In einer produktiven Anwendung würdest Du diese Werte vermutlich aus einer Konfigurationstabelle oder aus der Registry lesen, aber für unser Beispiel reicht die Lösung als Konstanten.<\/p>\n Die Funktion ADODB_GetConnection<\/b> baut aus diesen Konstanten eine Verbindungszeichenfolge zusammen und öffnet eine neue ADODB.Connection<\/b> (siehe Listing 5).<\/p>\n Listing 5: Verbindung zum SQL Server herstellen<\/span><\/b><\/p>\n Über die Konstante blnUseSSPI<\/b> steuern wir, ob die Verbindung per Windows-Authentifizierung (Integrated Security=SSPI<\/b>) oder per SQL Server-Authentifizierung mit Benutzername und Kennwort aufgebaut wird:<\/p>\n Als Provider verwenden wir MSOLEDBSQL<\/b>, den aktuellen OLE DB-Treiber für den SQL Server. Im Fehlerfall zeigen wir eine Meldung an und liefern Nothing<\/b> zurück, damit der aufrufende Code prüfen kann, ob die Verbindung erfolgreich war.<\/p>\n Der Kern des Wrappers steckt in der Funktion ADODB_BuildCommand<\/b> (siehe Listing 6). Sie ist als Private<\/b> deklariert, weil sie nur intern von den öffentlichen Funktionen aufgerufen wird. Ihre Aufgabe ist es, ein Command<\/b>-Objekt zu erzeugen, ihm die Verbindung und den Prozedurnamen zuzuweisen und anschließend die Werte aus einem Parameter-Array automatisch in die Parameter der gespeicherten Prozedur zu kopieren.<\/p>\n Listing 6: Command-Objekt bauen und Parameter füllen<\/span><\/b><\/p>\n Damit das funktioniert, müssen wir die Parameter-Definitionen der Prozedur kennen. Statt sie mühsam per Hand anzulegen, lassen wir ADODB diese Arbeit übernehmen. Die Methode Parameters.Refresh<\/b> fragt die Parameter-Informationen direkt vom SQL Server ab. Danach sind alle Parameter mit dem richtigen Datentyp, der richtigen Länge und der richtigen Richtung (Input, Output oder beides) bereits angelegt – wir müssen nur noch die Werte zuweisen.<\/p>\n Schauen wir uns die Logik der Funktion im Detail an. Nach dem Anlegen des Command<\/b>-Objekts weisen wir die Verbindung zu, setzen den Prozedurnamen und legen CommandType<\/b> auf adCmdStoredProc<\/b> fest. Der Aufruf von Parameters.Refresh<\/b> fragt die Parameterdefinitionen beim SQL Server ab und füllt die Parameters<\/b>-Auflistung des Command<\/b>-Objekts.<\/p>\n Danach ermitteln wir mit UBound<\/b> den höchsten Index des Parameter-Arrays. Das kann fehlschlagen, wenn das Array leer ist – deshalb kapseln wir die Zuweisung mit On Error Resume Next<\/b> und setzen lngMaxIndex<\/b> im Fehlerfall auf -1<\/b>. So stellen wir sicher, dass die nachfolgende Schleife auch bei leeren Parameter-Arrays sauber durchläuft.<\/p>\n In der For<\/b>-Schleife beginnen wir mit Index 1<\/b>, nicht mit 0<\/b>. Das liegt daran, dass ADODB beim Refresh an Position 0<\/b> immer einen impliziten Parameter mit dem Namen @RETURN_VALUE<\/b> für den Rückgabewert der Prozedur anlegt. Den brauchen wir hier nicht und überspringen ihn daher.<\/p>\n Innerhalb der Schleife prüfen wir die Richtung jedes Parameters. Nur Input- und Input-Output-Parameter erhalten einen Wert aus unserem Array – reine Output-Parameter werden vom SQL Server selbst gefüllt und dürfen nicht überschrieben werden. Die Variable lngCurrentParameter<\/b> zählt dabei, der wievielte Input-Parameter gerade verarbeitet wird. So kannst Du beim Aufruf einfach die Werte in der Reihenfolge der Eingabe-Parameter übergeben, ohne Output-Parameter mitzählen zu müssen.<\/p>\n Für den Fall, dass ein Wert im Array Null<\/b> ist, weisen wir explizit Null<\/b> zu. Das ist wichtig, weil Null<\/b>-Werte in VBA auf dem Weg durch Parameter-Arrays schon einmal zu Empty<\/b> umgedeutet werden und der SQL Server mit Empty<\/b> nichts anfangen kann.<\/p>\n Mit der Helferfunktion als Werkzeug werden die eigentlichen CRUD-Funktionen zu kurzen, übersichtlichen Routinen. Die Funktion ADODB_GetRecordset<\/b> ist für SELECT<\/b>-Prozeduren zuständig. Sie nimmt den Prozedurnamen sowie eine beliebige Anzahl von Parametern entgegen, lässt die Helferfunktion das Command<\/b>-Objekt bauen und öffnet darauf ein Recordset (siehe Listing 7).<\/p>\n Listing 7: Recordset per gespeicherter Prozedur abrufen<\/span><\/b><\/p>\n Drei Details sind an dieser Funktion erwähnenswert. Erstens verwenden wir ParamArray<\/b>, damit der Aufrufer eine beliebige Anzahl Parameter übergeben kann. Das Array arrParameters<\/b> weisen wir einer Variant<\/b>-Variablen zu – das macht die Weitergabe an die Helferfunktion deutlich einfacher. Zweitens setzen wir CursorLocation<\/b> auf adUseClient<\/b>. Das sorgt dafür, dass das Recordset lokal im Arbeitsspeicher gehalten wird – Voraussetzung für die dritte Besonderheit.<\/p>\n Drittens setzen wir ActiveConnection<\/b> nach dem Öffnen auf Nothing<\/b>. Damit trennen wir das Recordset von der Verbindung und können es als eigenständiges, bearbeitbares Recordset einem Formular oder einem Kombinationsfeld als Datenquelle zuweisen. Die Verbindung zum SQL Server ist also nur so lange offen, wie das Recordset gefüllt wird.<\/p>\n Die Funktion ADODB_ExecInsert<\/b> ruft eine INSERT<\/b>-Prozedur auf und liefert die neu vergebene ID zurück. Sie setzt voraus, dass die aufgerufene Prozedur einen Output-Parameter mit dem Namen @IDNEW<\/b> besitzt – was bei unserer spMitarbeiterInsert<\/b> genau so ist (siehe Listing 8).<\/p>\n Listing 8: INSERT-Prozedur ausführen<\/span><\/b><\/p>\n Nach dem Execute<\/b>-Aufruf greifen wir auf den Output-Parameter @IDNEW<\/b> zu und liefern dessen Wert als Long<\/b> zurück. Die Nz<\/b>-Funktion ersetzt einen eventuellen Null<\/b>-Wert durch -1<\/b> – so signalisiert die Funktion im Fehlerfall eindeutig, dass kein Datensatz angelegt wurde.<\/p>\n Die Funktionen ADODB_ExecUpdate<\/b> und ADODB_ExecDelete<\/b> sind nahezu identisch aufgebaut. Beide erwarten, dass die aufgerufene Prozedur einen Output-Parameter @RowsAffected<\/b> zurückliefert, und geben dessen Wert als Long<\/b> zurück. So weiß der aufrufende Code, wie viele Datensätze tatsächlich geändert oder gelöscht wurden (siehe Listing 9).<\/p>\n Listing 9: UPDATE-Prozedur ausführen<\/span><\/b><\/p>\n Die Funktion ADODB_ExecDelete<\/b> unterscheidet sich von ADODB_ExecUpdate<\/b> nur in den Bezeichnern innerhalb der Fehlermeldungen, die Logik ist identisch (siehe Listing 10).<\/p>\n Listing 10: DELETE-Prozedur ausführen<\/span><\/b><\/p>\n Nicht jede Prozedur gibt genau einen Output-Parameter mit dem Namen @IDNEW<\/b> oder @RowsAffected<\/b> zurück. Manche Prozeduren liefern mehrere Output-Werte, manche geben vielleicht auch einen @ReturnValue<\/b> zurück. Für solche Fälle gibt es die Funktion ADODB_ExecProc<\/b>, die das komplette Command<\/b>-Objekt nach der Ausführung zurückliefert (siehe Listing 11).<\/p>\n Listing 11: Generische Ausführung einer Prozedur<\/span><\/b><\/p>\n Mit dem zurückgegebenen Command<\/b>-Objekt kannst Du auf beliebige Output-Parameter zugreifen, etwa so:<\/p>\n Für den schnellen Funktionscheck legen wir im Modul noch vier kleine Testprozeduren an. Die folgende zeigt die Verwendung von ADODB_GetRecordset<\/b> mit einem Parameter:<\/p>\nCREATE PROCEDURE [dbo].[spMitarbeiterSelectNachMitarbeiterID]\r\n @MitarbeiterID INT = NULL\r\nAS\r\nSET NOCOUNT ON\r\nSELECT MitarbeiterID, AbteilungID, Vorname, Nachname, Email, Eintrittsdatum, Gehalt, ErstelltVon, ErstelltAm\r\nFROM tblMitarbeiter\r\nWHERE (@MitarbeiterID IS NULL\r\n OR MitarbeiterID = @MitarbeiterID)\r\nORDER BY Nachname, Vorname<\/pre>\n
CREATE PROCEDURE [dbo].[spMitarbeiterInsert]\r\n @AbteilungID INT,\r\n @Vorname NVARCHAR(100),\r\n @Nachname NVARCHAR(100),\r\n @Email NVARCHAR(255) = NULL,\r\n @Eintrittsdatum DATE = NULL,\r\n @Gehalt DECIMAL(10,2) = NULL,\r\n @IDNEW INT = -1 OUTPUT\r\nAS\r\nSET NOCOUNT ON\r\nINSERT INTO tblMitarbeiter (AbteilungID,\r\n Vorname, Nachname, Email,\r\n Eintrittsdatum, Gehalt)\r\nVALUES (@AbteilungID, @Vorname, @Nachname,\r\n @Email, @Eintrittsdatum, @Gehalt)\r\nSET @IDNEW = SCOPE_IDENTITY()<\/pre>\n
CREATE PROCEDURE [dbo].[spMitarbeiterUpdate]\r\n @MitarbeiterID INT,\r\n @AbteilungID INT,\r\n @Vorname NVARCHAR(100),\r\n @Nachname NVARCHAR(100),\r\n @Email NVARCHAR(255) = NULL,\r\n @Eintrittsdatum DATE = NULL,\r\n @Gehalt DECIMAL(10,2) = NULL,\r\n @RowsAffected INT = 0 OUTPUT\r\nAS\r\nSET NOCOUNT ON\r\nUpdate tblMitarbeiter\r\nSET AbteilungID = @AbteilungID,\r\n Vorname = @Vorname,\r\n Nachname = @Nachname,\r\n Email = @Email,\r\n Eintrittsdatum = @Eintrittsdatum,\r\n Gehalt = @Gehalt\r\nWHERE MitarbeiterID = @MitarbeiterID\r\nSET @RowsAffected = @@ROWCOUNT<\/pre>\n
CREATE PROCEDURE [dbo].[spMitarbeiterDelete]\r\n @MitarbeiterID INT,\r\n @RowsAffected INT = 0 OUTPUT\r\nAS\r\nSET NOCOUNT ON\r\nDELETE FROM tblMitarbeiter\r\nWHERE MitarbeiterID = @MitarbeiterID\r\nSET @RowsAffected = @@ROWCOUNT<\/pre>\n
Warum ein Wrapper?<\/h2>\n
Set<\/span> rst = ADODB_GetRecordset( _\r\n \"spMitarbeiterSelectNachMitarbeiterID\", 5)<\/pre>\nDie Verbindungsfunktion<\/h2>\n
Option Compare Database<\/span>\r\nOption Explicit<\/span>\r\nPrivate <\/span>Const strServer As String<\/span> = \"Dein Server\"\r\nPrivate <\/span>Const strDatabase As String<\/span> = \"Deine Datenbank\"\r\nPrivate <\/span>Const blnUseSSPI As Boolean<\/span> = True<\/span>\r\nPrivate <\/span>Const strUsr As String<\/span> = \"\"\r\nPrivate <\/span>Const strPwd As String<\/span> = \"\"<\/pre>\nPublic Function <\/span>ADODB_GetConnection() As <\/span>ADODB.Connection\r\n Dim <\/span>strConnection As String<\/span>\r\n Dim <\/span>cnn As <\/span>ADODB.Connection\r\n On Error GoTo<\/span> ErrHandler\r\n Set<\/span> cnn = New<\/span> ADODB.Connection\r\n If <\/span>blnUseSSPI Then<\/span>\r\n strConnection = \"Provider=MSOLEDBSQL;Data Source=\" & strServer & \";Initial Catalog=\" _\r\n & strDatabase & \";Integrated Security=SSPI;\"\r\n Else<\/span>\r\n strConnection = \"Provider=MSOLEDBSQL;Data Source=\" & strServer & \";Initial Catalog=\" _\r\n & strDatabase & \";User ID=\" & strUsr & \";Password=\" & strPwd & \";\"\r\n End If<\/span>\r\n cnn.Open strConnection\r\n Set<\/span> ADODB_GetConnection = cnn\r\n Exit Function<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler in ADODB_Connection:\" & vbCrLf<\/span> & Err.Description, vbCr<\/span>itical, \"DB Connection\"\r\n Set<\/span> ADODB_GetConnection = Nothing\r\nEnd Function<\/span><\/pre>\nDie Helferfunktion ADODB_BuildCommand<\/h2>\n
Private Function <\/span>ADODB_BuildCommand(ByVal strProcedure As String<\/span>, ByRef varParameters As Variant<\/span>) As <\/span>ADODB.Command\r\n Dim <\/span>cmd As <\/span>ADODB.Command\r\n Dim <\/span>intParameter As Integer<\/span>\r\n Dim <\/span>lngCurrentParameter As Long<\/span>\r\n Dim <\/span>lngMaxIndex As Long<\/span>\r\n Set<\/span> cmd = New<\/span> ADODB.Command\r\n cmd.ActiveConnection = ADODB_GetConnection\r\n cmd.CommandText = strProcedure\r\n cmd.CommandType = adCmdStoredProc\r\n cmd.Parameters.Refresh\r\n On Error Resume Next<\/span>\r\n lngMaxIndex = UBound<\/span>(varParameters)\r\n If <\/span>Err.Number <> 0 Then<\/span>\r\n lngMaxIndex = -1\r\n End If<\/span>\r\n On Error GoTo<\/span> 0\r\n lngCurrentParameter = 0\r\n For intParameter = 1 To cmd.Parameters.Count - 1\r\n If cmd.Parameters(intParameter).Direction = adParamInput _\r\n Or cmd.Parameters(intParameter).Direction = adParamInputOutput Then\r\n If <\/span>lngCurrentParameter <= lngMaxIndex Then<\/span>\r\n If <\/span>IsNull(varParameters(lngCurrentParameter)) Then<\/span>\r\n cmd.Parameters(intParameter).Value = Null\r\n Else<\/span>\r\n cmd.Parameters(intParameter).Value = varParameters(lngCurrentParameter)\r\n End If<\/span>\r\n lngCurrentParameter = lngCurrentParameter + 1\r\n End If<\/span>\r\n End If<\/span>\r\n Next<\/span> intParameter\r\n Set<\/span> ADODB_BuildCommand = cmd\r\nEnd Function<\/span><\/pre>\nSELECT: Recordset abrufen<\/h2>\n
Public Function <\/span>ADODB_GetRecordset(ByVal strProcedure As String<\/span>, ParamArray arrParameters() As Variant<\/span>) _\r\n As <\/span>ADODB.Recordset\r\n Dim <\/span>cmd As <\/span>ADODB.Command\r\n Dim <\/span>rst As <\/span>ADODB.Recordset\r\n Dim <\/span>varParameters As Variant<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n varParameters = arrParameters\r\n Set<\/span> cmd = ADODB_BuildCommand(strProcedure, varParameters)\r\n Set<\/span> rst = New<\/span> ADODB.Recordset\r\n rst.CursorLocation = adUseClient\r\n rst.Open cmd, , adOpenStatic, adLockOptimistic\r\n rst.ActiveConnection = Nothing\r\n Set<\/span> ADODB_GetRecordset = rst\r\n Exit Function<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler in ADODB_GetRecordset [\" & strProcedure & \"]:\" & vbCrLf<\/span> & Err.Description, vbCr<\/span>itical, _\r\n \"Fehler in ADODB_GetRecordset\"\r\n Set<\/span> ADODB_GetRecordset = Nothing\r\nEnd Function<\/span><\/pre>\nINSERT: Neuen Datensatz anlegen<\/h2>\n
Public Function <\/span>ADODB_ExecInsert(ByVal strProcedure As String<\/span>, ParamArray arrParameters() As Variant<\/span>) As Long<\/span>\r\n Dim <\/span>cmd As <\/span>ADODB.Command\r\n Dim <\/span>varParameters As Variant<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n varParameters = arrParameters\r\n Set<\/span> cmd = ADODB_BuildCommand(strProcedure, varParameters)\r\n cmd.Execute\r\n ADODB_ExecInsert = CLng(Nz(cmd.Parameters(\"@IDNEW\").Value, -1))\r\n Exit Function<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler in ADODB_ExecInsert [\" & strProcedure & \"]:\" & vbCrLf<\/span> & Err.Description, vbCr<\/span>itical, _\r\n \"Fehler in ADODB_ExecInsert\"\r\n ADODB_ExecInsert = -1\r\nEnd Function<\/span><\/pre>\nUPDATE und DELETE<\/h2>\n
Public Function <\/span>ADODB_ExecUpdate(ByVal strProcedure As String<\/span>, ParamArray arrParameters() As Variant<\/span>) As Long<\/span>\r\n Dim <\/span>cmd As <\/span>ADODB.Command\r\n Dim <\/span>varParameters As Variant<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n varParameters = arrParameters\r\n Set<\/span> cmd = ADODB_BuildCommand(strProcedure, varParameters)\r\n cmd.Execute\r\n ADODB_ExecUpdate = CLng(Nz(cmd.Parameters(\"@RowsAffected\").Value, 0))\r\n Exit Function<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler in ADODB_ExecUpdate [\" & strProcedure & \"]:\" & vbCrLf<\/span> & Err.Description, vbCr<\/span>itical, _\r\n \"Fehler in ADODB_ExecUpdate\"\r\n ADODB_ExecUpdate = -1\r\nEnd Function<\/span><\/pre>\nPublic Function <\/span>ADODB_ExecDelete(ByVal strProcedure As String<\/span>, ParamArray arrParameters() As Variant<\/span>) As Long<\/span>\r\n Dim <\/span>cmd As <\/span>ADODB.Command\r\n Dim <\/span>varParameters As Variant<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n varParameters = arrParameters\r\n Set<\/span> cmd = ADODB_BuildCommand(strProcedure, varParameters)\r\n cmd.Execute\r\n ADODB_ExecDelete = CLng(Nz(cmd.Parameters(\"@RowsAffected\").Value, 0))\r\n Exit Function<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler in ADODB_ExecDelete [\" & strProcedure & \"]:\" & vbCrLf<\/span> & Err.Description, vbCr<\/span>itical, _\r\n \"Fehler in ADODB_ExecDelete\"\r\n ADODB_ExecDelete = -1\r\nEnd Function<\/span><\/pre>\nGenerische Ausführung mit ADODB_ExecProc<\/h2>\n
Public Function <\/span>ADODB_ExecProc(ByVal strProcedure As String<\/span>, ParamArray arrParameters() As Variant<\/span>) As <\/span>ADODB.Command\r\n Dim <\/span>cmd As <\/span>ADODB.Command\r\n Dim <\/span>varParameters As Variant<\/span>\r\n On Error GoTo<\/span> ErrHandler\r\n varParameters = arrParameters\r\n Set<\/span> cmd = ADODB_BuildCommand(strProcedure, varParameters)\r\n cmd.Execute\r\n Set<\/span> ADODB_ExecProc = cmd\r\n Exit Function<\/span>\r\nErrHandler:\r\n MsgBox<\/span> \"Fehler in ADODB_ExecProc [\" & strProcedure & \"]:\" & vbCrLf<\/span> & Err.Description, vbCr<\/span>itical, _\r\n \"Fehler in ADODB_ExecProc\"\r\n Set<\/span> ADODB_ExecProc = Nothing\r\nEnd Function<\/span><\/pre>\nDim <\/span>cmd As <\/span>ADODB.Command\r\nSet<\/span> cmd = ADODB_ExecProc( _\r\n \"spIrgendeineProzedur\", 42)\r\nDebug.Print<\/span> cmd.Parameters(\"@Ergebnis\").Value<\/pre>\nTests im Direktbereich<\/h2>\n