<\/p>\n
Im Beitrag „RDBMS-Zugriff per VBA: Verbindungen“ haben wir die Grundlage für den Zugriff auf SQL Server-Datenbanken geschaffen. Zudem zeigt der Beitrag „RDBMS-Zugriff per VBA: Daten abfragen“, wie Sie die Daten einer SQL Server-Datenbank ermitteln. Im vorliegenden Teil dieser Beitragsreihe erfahren Sie nun, wie Sie die Daten einer SQL Server-Datenbank bearbeiten.<\/b><\/p>\nAktionsabfragen<\/h2>\n
Aktionsabfragen sind Abfragen, die Daten ändern – also Lösch-, Aktualisierungs- und An-füge-ab-fra-gen. In reinen Access-Datenbanken führen Sie solche Abfragen aus, indem Sie diese mit dem Abfrage-Entwurf erstellen und direkt ausführen oder per VBA aufrufen oder indem Sie die gewünschte Abfrage als SQL-Ausdruck per Code zusammenstellen und dann mit der Execute<\/b>-Methode des Database<\/b>-Objekts ausführen. Für SQL Server-Daten gibt es die folgenden Arten der Ausführung:<\/p>\n Wenn es um die Performance geht, ist die erste Variante die langsamste, die zweite Version ist etwas schneller und die dritte Version ändert die Daten in der Regel am schnellsten. Aus diesem Grund schauen wir uns nachfolgend lediglich die zweite und die dritte Variante an.<\/p>\n Bei der ersten Variante legen Sie eine Pass-Through-Abfrage mit der auszuführenden DELETE<\/b>-Anweisung an (s. Bild 1).<\/p>\n Bild 1: Die neue PassThrough-Abfrage zum Löschen eines Datensatzes im SQL Server<\/span><\/b><\/p>\n Dazu sind folgende Schritte nötig:<\/p>\n Die DELETE<\/b>-Anweisung soll in unserem Fall wie folgt lauten:<\/p>\n Die Abfrage können Sie dann per VBA mit einer einzigen Anweisung ausführen:<\/p>\n Sie können auch die Variante mit dem QueryDefs<\/b>-Objekt verwenden:<\/p>\n Damit haben Sie allerdings noch nicht viel gewonnen: Die Anweisung löscht ja nur genau den Datensatz, dessen ID Sie als Kriterium angegeben haben. Immerhin haben wir aber bereits eine Abfrage erstellt, die den richtigen Typ aufweist, die Ver-bin-dungszeichenfolge enthält und deren Eigenschaft Liefert Datensätze <\/b>auf Nein <\/b>eingestellt ist. Diese nutzen wir nun, um gezielt einen bestimmten Datensatz zu löschen. Die folgende Prozedur (wie auch die weiteren Beispiele im Modul mdlRDBMSZugriff_DatenBearbeiten<\/b>) erwartet den Primärschlüsselwert des zu löschenden Datensatzes als Parameter:<\/p>\n Mit dieser Prozedur referenzieren wir die soeben erstellte Abfrage qryPTDeleteKategorie <\/b>und ändern die enthaltene SQL-Anweisung so, dass diese als Kriterium den per Parameter übergebenen Primärschlüsselwert enthält.<\/p>\n Danach führen wir die geänderte Abfrage mit der Execute<\/b>-Anweisung aus. Der Aufruf dieser Prozedur sieht etwa so aus:<\/p>\n Diese Variante hat noch folgende Nachteile:<\/p>\n In den folgenden beiden Abschnitten kümmern wir uns um diese Nachteile.<\/p>\n Als Erstes sorgen wir dafür, dass der SQL Server unabhängig vom übergebenen Parameter nur einen Ausführungsplan für die Abfrage erstellt, speichert und bei weiteren Aufrufen wiederverwendet. Dazu erstellen wir eine gespeicherte Prozedur, und zwar mit folgendem SQL-Skript:<\/p>\n Dieses Skript können Sie, wenn Sie es von Access aus ausführen möchten, in das Formular frmSQLBefehle <\/b>eingeben und dann mit der Ausführen<\/b>-Schaltfläche ausführen (s. Bild 2). Ob die gespeicherte Prozedur erfolgreich angelegt wurde, können Sie mit der folgenden Anweisung, ebenfalls in diesem Formular abgesetzt, prüfen:<\/p>\n Bild 2: Anlegen einer gespeicherten Prozedur per Access-Formular<\/span><\/b><\/p>\n Die gespeicherte Prozedur spDELETEKategorieNachID <\/b>erwartet den Primärschlüsselwert des zu löschenden Datensatzes als Parameter. Wenn Sie die gespeicherte Prozedur direkt vom Abfragefenster des SQL Servers aus ausführen wollten, würden Sie dies mit folgender Anweisung erledigen:<\/p>\n Sie können auch diese Abfrage im Formular frmSQLBefehle <\/b>absetzen, aber es gibt noch eine andere Variante – zum Beispiel für den Fall, dass Sie diese gespeicherte Prozedur per Code aufrufen wollen.<\/p>\n Also erstellen Sie zunächst eine neue Abfrage, wandeln diese in eine Pass-Through-Abfrage um und legen den SQL-Ausdruck aus Bild 3 fest.<\/p>\n Bild 3: Aufruf einer gespeicherten Abfrage per Passthrough-Abfrage<\/span><\/b><\/p>\n In dieser Abfrage müssen Sie nun natürlich ebenfalls den Primärschlüsselwert des zu löschenden Datensatzes als Parameter angeben. Dies erledigen Sie ähnlich wie oben:<\/p>\n Der Aufruf sieht beispielsweise wie folgt aus:<\/p>\n Dies ändert zunächst den SQL-Ausdruck der Abfrage ptKategorieLoeschen <\/b>wie folgt:<\/p>\n Dieser Aufruf wird direkt an den SQL Server gesendet, der dann die gespeicherte Prozedur spDELETEKategorie-NachID <\/b>mit dem angegebenen Parameter ausführt und den entsprechenden Datensatz löscht.<\/p>\n Nun soll noch die Verbindungszeichenfolge direkt aus der Tabelle tblVerbindungszeichenfolgen <\/b>bezogen werden (Erläuterungen zu dieser Tabelle siehe RDBMS-Zugriff per VBA: Verbindungen<\/b>, www.access-im-unternehmen.de\/1054<\/b>). Dazu übergeben Sie der VBA-Prozedur noch die ID der Verbindungszeichenfolge als weiteren Parameter. Dieser Parameter wird an die in dem oben erwähnten Beitrag erläuterte Funktion Ver-bin-dungs-zeichenfolgeNachID <\/b>übergeben, die dann die Verbindungszeichenfolge zurückliefert. Das Ergebnis landet direkt in der Eigenschaft Connect <\/b>des QueryDef<\/b>-Objekts, was dem Zuweisen der Verbindungszeichenfolge zur Eigenschaft ODBC-Verbindung <\/b>entspricht. Die Prozedur finden Sie in Listing 1. Auch hier noch ein Beispielaufruf:<\/p>\n Listing 1: Aufruf einer gespeicherten Prozedur mit dynamischer Verbindungszeichenfolge<\/span><\/b><\/p>\n Dies löscht den Datensatz mit dem Wert 107 <\/b>im Feld KategorieID <\/b>und verwendet die Verbindungszeichenfolge mit dem Wert 9 <\/b>im Feld VerbindungszeichenfolgeID <\/b>der Tabelle tblVerbindungszeichenfolgen<\/b>.<\/p>\n Sie können die Verbindungszeichenfolge natürlich auch mit der Funktion Standard-ver-bin-dungs-zeichenfolge <\/b>ermitteln. Dazu ersetzen Sie die Zeile mit der Connect<\/b>-Eigenschaft wie folgt:<\/p>\n Oder Sie übergeben die Standardverbindungszeichenfolge beim Aufruf:<\/p>\n Schließlich möchten Sie vielleicht noch wissen, ob der Löschvorgang überhaupt erfolgreich war beziehungsweise wie viele Datensätze von der Aktionsabfrage betroffen waren. T-SQL bietet mit der Funktion @@ROWCOUNT <\/b>ein Mittel, um die Anzahl der von der zuletzt ausgeführten Abfrage betroffenen Datensätze zu ermitteln. Dies bezieht sich auf die Aktionsabfragen der aktuellen Verbindung. Die folgende gespeicherte Prozedur löscht wie in den obigen Beispielen einen Datensatz mit dem übergebenen Wert für das Feld KategorieID<\/b>, gibt aber als Ergebnis die Anzahl der betroffenen Datensätze zurück:<\/p>\n Wenn Sie diese gespeicherte Prozedur im Abfragefenster im SQL Server Management Studio <\/b>aufrufen, sieht das Ergebnis wie in Bild 4 aus. Um dieses Ergebnis von Access aus zu nutzen, ist eine kleine änderung am Entwurf der Pass-Through-Abfrage nötig.<\/p>\n Bild 4: Ergebnis einer gespeicherten Prozedur im SQL Server Management Studio<\/span><\/b><\/p>\n Wir haben die Abfrage von oben unter dem Namen qrySPDELETEKategorieNachIDMitErgebnis<\/b> kopiert und die Eigenschaft Liefert Datensätze <\/b>auf den Wert Ja <\/b>eingestellt (s. Bild 5). Anderenfalls liefert die Abfrage das Ergebnis der SELECT<\/b>-Abfrage mit der Anzahl der betroffenen Datensätze nicht zurück!<\/p>\n Bild 5: Entwurf der Passthrough-Abfrage zum Löschen eines Datensatzes mit Rückgabe der betroffenen Datensätze<\/span><\/b><\/p>\n Führen Sie diese Abfrage direkt aus, liefert sie das Ergebnis aus Bild 6.<\/p>\n Bild 6: Ergebnis der gespeicherten Prozedur innerhalb einer Pass-Through-Abfrage in Access<\/span><\/b><\/p>\n Dies ist ein Ergebnis, mit dem wir auch unter VBA arbeiten können. Die Prozedur aus Listing 2 verwendet wieder die KategorieID<\/b> und ermittelt die Verbindungszeichenfolge mit der Funktion Stan-dard-verbindungszeichenfolge<\/b>. Sie erzeugt wie gewohnt ein QueryDef<\/b>-Objekt auf Basis einer neuen gespeicherten Access-Abfrage namens spDELETEKategorie-NachIDMitErgebnis <\/b>und ermittelt die gewünschte Ver-bin-dungs-zei-chenfolge. Dann weist sie wie zuvor den neuen SQL-Ausdruck zu, führt die Abfrage aber diesmal nicht mit Execute <\/b>aus. Stattdessen erstellt sie ein neues Recordset<\/b>-Objekt und füllt es über die OpenRecordset<\/b>-Methode mit dem Ergebnis der gespeicherten Prozedur. Dies erzeugt ein herkömmliches Recordset<\/b>-Objekt, das nur einen Datensatz mit einem Feld enthält – und dieses wird mit rst!RecordsetAffected<\/b> ausgelesen und in einem Meldungsfenster ausgegeben.<\/p>\n <\/p>\n Listing 2: Aufruf einer gespeicherten Prozedur mit Rückgabewert<\/span><\/b><\/p>\n Die bisherigen Ansätze gingen davon aus, dass die Access-Datenbank eine gespeicherte Access-Abfrage mit den wichtigsten Eigenschaften zum Ausführen der gespeicherten Prozedur per Pass-Through-Abfrage enthält. Je mehr solcher Abfragen Sie verwenden, desto unübersichtlicher wird es im Navigationsbereich. Und davon abgesehen ändern wir ohnehin zumindest den SQL-Code jeder Pass-Through-Abfrage, die eine gespeicherte Prozedur mit Parametern ausführt. Dann könnten wir diese auch gleich neu anlegen – der Performance-Unterschied dürfte sich in Grenzen halten. Es gibt jedoch auch die Möglichkeit, ein QueryDef<\/b>-Objekt komplett temporär zu erzeugen.<\/p>\n Was benötigen wir also im Vergleich zur vorherigen Variante Eigentlich müssen wir nur den Namen der zu verwendenden gespeicherten Prozedur zusätzlich übergeben, die Ver-bin-dungs-zeichenfolge und die Parameter werden ja bereits verarbeitet. Außerdem referenzieren wir nicht über die QueryDefs<\/b>-Auflistung eine bestehende Abfrage, sondern erstellen mit CreateQueryDef<\/b> eine neue – und zwar mit einer leeren Zeichenkette als Name. Die Prozedur sieht nun wie in Listing 3 aus. Sie erstellt mit der CreateQueryDef<\/b>-Methode eine temporäre Abfrage, was wir dadurch erreichen, dass wir eine leere Zeichenfolge als Parameter übergeben. <\/p>\n Listing 3: Prozedur, welche die angegebene gespeicherte Prozedur mit gegebener Verbindungszeichenfolge und Parametern ausführt<\/span><\/b><\/p>\n Für die Parameterliste verwenden wir im Kopf der Prozedur einen Parameter namens varParameter <\/b>des Typs ParamArray<\/b>, dem man beliebig viele durch Kommata getrennte Parameterwerte übergeben kann. Die damit übergebenen Werte setzt die Prozedur in einer For Each<\/b>-Schleife über alle Elemente von varParameter <\/b>zusammen und stellt jeweils ein Komma voran. Das erste Komma wird danach gegebenenfalls abgeschnitten. Die folgenden Zeilen stellen die Ver-bin-dungszeichenfolge ein, legen für ReturnRecords<\/b> den Wert False <\/b>fest und fügen das Schlüssel-wort EXEC<\/b>, den Namen der gespeicherten Prozedur und die Parameterliste zusammen. Die Execute<\/b>-Methode führt die Abfrage schließlich durch. Ein Beispielaufruf sieht etwa so aus:<\/p>\n Um auch hier die Standardverbindungszeichenfolge zu verwenden, nutzen Sie folgenden Aufruf:<\/p>\n Für verschiedene Zwecke ist es interessant, den Autowert des zuletzt hinzugefügten Datensatzes zu ermitteln. Dies gilt nur für die VBA-Varianten: also das Hinzufügen mit der DAO-Methode AddNew <\/b>oder mit der per Execute <\/b>aufgerufenen INSERT INTO<\/b>– oder SELECT INTO<\/b>-SQL-Anweisung. Die folgenden Abschnitte zeigen die Variante für lokale Tabellen sowie für das Hinzufügen von Datensätzen zu Tabellen einer SQL Server-Datenbank.<\/p>\n Die erste Variante ist die oft verwendete DAO-Methode mit den beiden Anweisungen AddNew <\/b>und Update<\/b>, wobei zwischen diesen beiden Anweisungen die neuen Feldwerte angegeben werden. Dies ist die Access-Variante, bei welcher der Wert des Primärschlüsselfelds für den neuen Datensatz bereits nach dem Aufruf der AddNew<\/b>-Methode belegt ist und ausgelesen werden kann – hier am Beispiel der lokalen Tabelle tblKategorien_Lokal<\/b>:<\/p>\n Führen wir diese Prozedur in einer Beispieldatenbank aus, die eine per ODBC verknüpfte SQL Ser-ver-Ta-belle namens tblKategorien <\/b>enthält, liefert dies den Fehler aus Bild 7. Dies besagt, dass Sie auf eine SQL Server-Tabelle mit einem Primärschlüsselwert (IDENTITY<\/b>) nur zu-grei-fen können, wenn Sie den Parameter dbSeeChanges <\/b>verwenden. Diesen Fehler beheben wir in der folgenden Variante. Dort fügen wir in der Zeile mit der Open-Re-cordset<\/b>-Methode zunächst den Wert dbSeeChanges <\/b>für den dritten Parameter hinzu:<\/p>\n Bild 7: Fehler beim Versuch, ein Recordset ohne die Option db-See-Changes zu öffnen<\/span><\/b><\/p>\n Die Prozedur läuft nun durch, die Debug.Print<\/b>-Anweisung liefert jedoch keinen Wert für das Feld KategorieID<\/b>, also das durch den SQL Server mit einem Autowert zu füllende Pri-mär-schlüsselfeld:<\/p>\n Der Grund liegt darin, dass der SQL Server den Autowert für das Primärschlüsselfeld erst vergibt, wenn der Datensatz gespeichert wird. Hilft es also, wenn wir den Wert des Primärschlüsselfeldes erst nach dem Aufruf von Update <\/b>abfragen Nein – AddNew<\/b> und Update <\/b>verschieben den Da-ten-satzzeiger nicht auf den neuen Datensatz, sondern dieser verbleibt auf dem Datensatz, auf den der Zeiger vor dem Anlegen bereits zeigte (in diesem Fall auf den ersten Datensatz des Recordsets):<\/p>\n Hier kommt die Eigenschaft LastModified <\/b>des DAO-Recordsets zum Einsatz. Stellen wir die Ei-gen-schaft Bookmark <\/b>nach dem Einfügen des Datensatzes auf den Wert der Eigenschaft Last-Mo-di-fied <\/b>ein, wird der Datensatzzeiger auf den neuen Datensatz verschoben und wir können den Primärschlüsselwert auslesen:<\/p>\n Wenn Sie das obige Beispiel zweimal hintereinander ausführen, ohne den Code zu ändern, löst dies den Fehler aus Bild 8 aus. Die Fehlermeldung ODBC-Aufruf fehlgeschlagen <\/b>weist lediglich darauf hin, dass beim Zugriff auf den SQL Server ein Fehler aufgetreten ist. Genauere Informationen erhalten Sie über die Errors<\/b>-Auflistung der DAO-Bibliothek. Die Count<\/b>-Eigenschaft liefert die Anzahl der Einträge – im Direktbereich etwa so (nach dem Quittieren der obigen Fehlermeldung mit einem Klick auf die Schaltfläche Debuggen<\/b>):<\/p>\n Bild 8: Fehler beim Versuch, einen bereits vorhandenen Wert in ein eindeutiges Feld zu schreiben<\/span><\/b><\/p>\n Der letzte Fehler der Auflistung mit dem Index 2 <\/b>ist der, den auch das Err<\/b>-Objekt und die Fehlermeldung liefern:<\/p>\n Der zweite Fehler basiert auf folgender Nummer und Meldung:<\/p>\n Auch diese Meldung liefert keine entscheidenden Informationen. Bleibt noch die Meldung mit dem Index 0<\/b>:<\/p>\n Wir haben also schlicht versucht, einen Wert in das Feld Kategoriename <\/b>einzutragen, der bereits vorhanden war. Und da für dieses Feld ein eindeutiger Index festgelegt wurde, löst der SQL Server einen entsprechenden Fehler aus.<\/p>\n Unter Access verwendet man bei Datensatzänderungen, die durch INSERT INTO<\/b>– und SELECT INTO<\/b>-Abfragen durchgeführt wurden, eine spezielle Abfrage zum Ermitteln des Primärschlüsselwertes des zuletzt hinzugefügten Datensatzes. Ein Beispiel sieht wie folgt aus:<\/p>\n\n
Datensatz löschen per SQL<\/h2>\n
![\"Die](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_001.png\")
<\/p>\n\n
DELETE FROM tblKategorien WHERE KategorieID = 12<\/pre>\n
CurrentDb.Execute \"qryPTDeleteKategorie\"<\/pre>\n
CurrentDb.QueryDefs(\"qryPTDeleteKategorie\").Execute<\/pre>\n
Public Sub <\/span>KategorieLoeschen_PT(lngKategorieID As Long<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> qdf = db.QueryDefs(\"qryPTDeleteKategorie\")\r\n qdf.SQL = \"DELETE FROM dbo.tblKategorien WHERE KategorieID = \" & lngKategorieID\r\n qdf.Execute\r\n Set<\/span> qdf = Nothing\r\n Set<\/span> db = Nothing\r\nEnd Sub<\/span><\/pre>\nKategorieLoeschen_PT 104<\/pre>\n
\n
Datensatz löschen per gespeicherter Prozedur<\/h2>\n
CREATE PROCEDURE dbo.spDELETEKategorieNachID (@KategorieID int)\r\nAS\r\nSET NOCOUNT ON;\r\nDELETE FROM tblKategorien \r\nWHERE KategorieID = @KategorieID;<\/pre>\n
![\"Anlegen](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_002.png\")
<\/p>\nSELECT * FROM Suedsturm.information_schema.routines \r\nWHERE routine_type = ''PROCEDURE''<\/pre>\n
EXEC dbo.spDELETEKategorieNachID 105<\/pre>\n
![\"Aufruf](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_003.png\")
<\/p>\nPublic Sub <\/span>KategorieLoeschen_PT_SP(lngKategorieID As Long<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> qdf = db.QueryDefs(\"qryPTDeleteKategorie\")\r\n qdf.SQL = \"EXEC dbo.spDELETEKategorieNachID \" & lngKategorieID\r\n qdf.Execute\r\n Set<\/span> qdf = Nothing\r\n Set<\/span> db = Nothing\r\nEnd Sub<\/span><\/pre>\nKategorieLoeschen_PT_SP 106<\/pre>\n
EXEC dbo.spDELETEKategorieNachID 106<\/pre>\n
Pass-Through-Abfrage mit dynamischer Verbindungszeichenfolge<\/h2>\n
Public Sub <\/span>KategorieLoeschenNachID_PT_SP_Connection(lngKategorieID As Long<\/span>, _\r\n lngVerbindungszeichenfolgeID As Long<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> qdf = db.QueryDefs(\"qryPTDELETEKategorie\")\r\n qdf.Connect = VerbindungszeichenfolgeNachID(lngVerbindungszeichenfolgeID)\r\n qdf.SQL = \"EXEC dbo.spDELETEKategorieNachID \" & lngKategorieID\r\n qdf.Execute\r\n Set<\/span> qdf = Nothing\r\n Set<\/span> db = Nothing\r\nEnd Sub<\/span><\/pre>\nKategorieLoeschenNachID_PT_SP_Connection 107, 9<\/pre>\n
qdf.Connect = Standardverbindungszeichenfolge<\/pre>\n
KategorieLoeschenNachID_PT_SP_Connection 108, StandardverbindungszeichenfolgeID<\/pre>\n
Löschen mit Bestätigung<\/h2>\n
CREATE PROCEDURE dbo.spDELETEKategorieNachIDMitErgebnis\r\n@KategorieID INT\r\nAS\r\nSET NOCOUNT ON;\r\nDELETE FROM tblKategorien WHERE KategorieID = @KategorieID\r\nSELECT @@ROWCOUNT AS RecordsAffected;<\/pre>\n
![\"Ergebnis](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_004.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_005.png\")
<\/p>\n![\"Ergebnis](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_006.png\")
<\/p>\nPublic Sub <\/span>KategorieLoeschenNachID_PT_SP_Connection_MitErgebnis(lngKategorieID As Long<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>lngAnzahl As Long<\/span>\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> qdf = db.QueryDefs(\"qryPTSPDELETEKategorieNachIDMitErgebnis\")\r\n qdf.Connect = Standardverbindungszeichenfolge\r\n qdf.SQL = \"EXEC dbo.spDELETEKategorieNachIDMitErgebnis \" & lngKategorieID\r\n Set<\/span> rst = qdf.OpenRecordset(dbOpenSnapshot)\r\n lngAnzahl = rst!RecordsAffected\r\n MsgBox<\/span> \"Es wurden \" & lngAnzahl & \" Datensätze gelöscht.\"\r\n Set<\/span> rst = Nothing\r\n Set<\/span> qdf = Nothing\r\n Set<\/span> db = Nothing\r\nEnd Sub<\/span><\/pre>\nDynamische Aktionsabfrage ohne Rückgabewert<\/h2>\n
Public Sub <\/span>TemporaerePTSPMitParameterAusfuehren(strStoredProcedure As String<\/span>, _\r\n lngVerbindungszeichenfolgeID As Long<\/span>, _\r\n ParamArray varParameter() As Variant<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n Dim <\/span>strParameter As String<\/span>\r\n Dim <\/span>var As Variant<\/span>\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> qdf = db.CreateQueryDef(\"\")\r\n For Each var In varParameter\r\n strParameter = strParameter & \", \" & var\r\n Next<\/span> var\r\n If <\/span>Len<\/span>(strParameter) > 0 Then<\/span>\r\n strParameter = Mid<\/span>(strParameter, 3)\r\n End If<\/span>\r\n With<\/span> qdf\r\n .Connect = VerbindungszeichenfolgeNachID(lngVerbindungszeichenfolgeID)\r\n .ReturnsRecords = False<\/span>\r\n .SQL = \"EXEC \" & strStoredProcedure & \" \" & strParameter\r\n .Execute\r\n End With<\/span>\r\n Set<\/span> db = Nothing\r\nEnd Sub<\/span><\/pre>\nTemporaerePTSPMitParameterAusfuehren \"spDELETEKategorieNachIDMitErgebnis\",9,112<\/pre>\n
TemporaerePTSPMitParameterAusfuehren \"spDELETEKategorieNachIDMitErgebnis\", _\r\n StandardverbindungszeichenfolgeID, 112<\/pre>\n
Autowert des zuletzt hinzugefügten Datensatzes ermitteln<\/h2>\n
Variante I: AddNew\/Update<\/h2>\n
Public Sub <\/span>NeuerDatensatzMitID_Lokal()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset( \"SELECT * FROM tblKategorien_Lokal\", dbOpenDynaset)\r\n rst.AddNew<\/span>\r\n Debug.Print<\/span> \"Neue KategorieID: \" & rst!KategorieID\r\n rst!Kategoriename = \"Beispielkategorie\"\r\n rst!Beschreibung = \"Beispielbeschreibung\"\r\n rst.Update\r\n rst.Close\r\n Set<\/span> rst = Nothing\r\n Set<\/span> db = Nothing\r\nEnd Sub<\/span><\/pre>\n![\"Fehler](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_007.png\")
<\/p>\nSet<\/span> rst = db.OpenRecordset(\"SELECT * FROM tblKatgorien\", dbOpenDynaset, dbSeeChanges)<\/pre>\nDebug.Print<\/span> \"Neue KategorieID: \" & rst!KategorieID\r\nNeue KategorieID:<\/pre>\nrst.AddNew<\/span>\r\nrst!Kategoriename = \"Beispielkategorie1\"\r\nrst!Beschreibung = \"Beispielbeschreibung\"\r\nrst.Update\r\nDebug.Print<\/span> \"Neue KategorieID: \" & rst!KategorieID<\/pre>\nrst.Update\r\nrst.Bookmark = rst.LastModified\r\nDebug.Print<\/span> \"Neue KategorieID: \" & rst!KategorieID<\/pre>\nFehler ermitteln unter DAO<\/h2>\n
![\"Fehler](\"..\/fileadmin\/_temp_\/2017_01\/pic_1074_008.png\")
<\/p>\n DAO.Errors.Count\r\n 3 <\/pre>\n
DAO.Errors(2).Number, DAO.Errors(2).Description\r\n 3146 ODBC-Aufruf fehlgeschlagen.<\/pre>\n
DAO.Errors(1).Number, DAO.Errors(1).Description\r\n 3621 [Microsoft][SQL Server Native Client 11.0][SQL Server]Die Anweisung wurde beendet.<\/pre>\n
DAO.Errors(0).Number, DAO.Errors(0).Description\r\n 2601 [Microsoft][SQL Server Native Client 11.0][SQL Server]Eine Zeile mit doppeltem _\r\nSchlüssel kann in das dbo.tblKategorien-Objekt mit dem eindeutigen IX_tblKategorien-Index _\r\nnicht eingefügt werden. Der doppelte Schlüsselwert ist (Beispielkategorie1).<\/pre>\n
Variante II: Execute\/INSERT INTO<\/h2>\n
Public Sub <\/span>NeuerDatensatzExecute()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>lngID