Und hier sind die beiden Methoden:<\/p>\n
- \n
- Clear<\/b>: Setzt alle Fehlerinformationen zurück (Number = 0, Description = “”, et cetera).<\/li>\n
- Raise<\/b>: Erzeugt einen benutzerdefinierten Fehler mit einer bestimmten Fehlernummer.<\/li>\n<\/ul>\n
Unter DAO gibt es dagegen wesentlich weniger Elemente. Die Fehlerklasse heißt hier auch nicht ErrObject<\/b>, sondern Error<\/b>. Hier gibt es nur (Beschreibung wie bei VBA):<\/p>\n
- \n
- Description<\/b><\/li>\n
- Number<\/b><\/li>\n
- Source<\/b><\/li>\n<\/ul>\n
Unter ADO finden wir wieder fast die gleichen Eigenschaften wie unter VBA, nämlich Description<\/b>, HelpContext<\/b>, HelpFile<\/b>, Number <\/b>und Source<\/b>. Wir finden aber auch zwei weitere Eigenschaften:<\/p>\n
- \n
- NativeError<\/b>: Liefert uns die Server-spezifische Fehlernummer. So erhalten wir beispielsweise für den gleichen Fehler im VBA-Error die Nummer -2147217873 <\/b>und im ADODB-Error die Nummer 547<\/b>.<\/li>\n
- SQLState<\/b>: Gibt den SQL-Fehlercode im standardisierten 5-stelligen Zeichenformat zurück. Diese Codes folgen dem SQL-92-Standard und sind von der Datenbank unabhängig.<\/li>\n<\/ul>\n
Fehler beim Zugriff mit DAO auswerten<\/h2>\n
Wenn beim Zugriff auf eine SQL Server-Datenbank über eine Tabellenverknüpfung oder andere Zugriffe per ODBC Fehler auftreten, können wir diese mit der herkömmlichen Err<\/b>-Klasse nur bedingt analysieren.<\/p>\n
Der Grund ist, dass wir mit der Err<\/b>-Klasse nur Informationen zum letzten aufgetretenen Fehler erhalten. Das ist auch so, wenn wir per Tabellenverknüpfung auf eine per ODBC verknüpfte Datenbank zugreifen. Hier können wir dann jedoch die Errors<\/b>-Auflistung von DAO hinzuziehen. Hier finden wir jedoch noch ein weiteres Problem vor, nämlich dass die Err<\/b>-Klasse immer nur eine generische Meldung liefert, die keinen Hinweis auf den tatsächlichen Fehler enthält. Die folgenden Anweisungen sollten beispielsweise einen Fehler auslösen, weil wir dem Feld AnlageID <\/b>keinen Wert zuweisen können:<\/p>\n
Dim <\/span>db As <\/span>DAO.Database\r\nDim <\/span>rst As <\/span>DAO.Recordset\r\nSet<\/span> db = CurrentDb\r\ndb.Execute \"INSERT INTO tblAnlagen(AnlageID) VALUES(1)\", dbFailOnError + dbSeeChanges<\/pre>\nWir erhalten dafür jedoch lediglich die Fehlermeldung aus Bild 1.<\/p>\n
![\"Fehler](\"..\/fileadmin\/_temp_\/2024_06\/pic_451_006.png\")
<\/p>\nBild 1: Fehler beim Ausführen einer SQL Server-Abfrage<\/span><\/b><\/p>\n
Fehler mit DAO.Errors auswerten<\/h2>\n
Es gibt jedoch nicht nur das Err<\/b>-Objekt, um Fehler auszuwerten. Wir können auch die DAO.Errors<\/b>-Auflistung bemühen, um den tatsächlich vom SQL Server gelieferten Fehler zu erhalten. Diese liefert uns Elemente des gleichen Typs wie unser bekanntes Error<\/b>-Objekt. Diese können wir in einer Schleife über die Errors<\/b>-Auflistung der DAO-Klasse durchlaufen:<\/p>\n
For i = 0 To DAO.Errors.Count\r\n Debug.Print<\/span> i, DAO.Errors(i).Description\r\nNext<\/span> i<\/pre>\nWir schauen uns diese Codezeilen einmal im Zusammenhang mit einer Prozedur an, die einen entsprechenden Fehler auslöst (siehe Listing 1). Hier erhalten wir die Fehlermeldungen, wie sie auch im SQL Server angezeigt werden:<\/p>\n
Public Sub <\/span>DAOFehlerAnalysieren()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>i As Integer<\/span>\r\n Set<\/span> db = CurrentDb\r\n On Error Resume Next<\/span>\r\n db.Execute \"INSERT INTO tblAnlagen(AnlageID) VALUES(1)\", dbFailOnError + dbSeeChanges\r\n Debug.Print<\/span> db.RecordsAffected, Err.Number\r\n Debug.Print<\/span> \"DAO.Errors:\"\r\n For i = 0 To DAO.Errors.Count\r\n Debug.Print<\/span> i, DAO.Errors(i).Description\r\n Next<\/span> i\r\nEnd Sub<\/span><\/pre>\nListing 1: Analysieren von Fehlern beim DAO-Zugriff auf ODBC-Verbindungen<\/span><\/b><\/p>\n
[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Verletzung der PRIMARY KEY-Einschränkung \"tblAnlagen$PrimaryKey\". Ein doppelter Schlüssel kann in das dbo.tblAnlagen-Objekt nicht eingefügt werden. Der doppelte Schlüsselwert ist (1).\r\n[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Die Anweisung wurde beendet.\r\nODBC-Aufruf fehlgeschlagen.<\/pre>\n
Fehlerbehandlung unter ADODB<\/h2>\n
Das ist bei Fehlern bei Datenbankzugriffen mit ADODB bereits etwas besser gelöst – hier erhalten wir eine aussagekräftige Fehlermeldung. Wir lösen in Listing 2 den gleichen Fehler aus wie in der DAO-Version, nur diesmal über die Execute<\/b>-Methode der Connection<\/b>-Klasse.<\/p>\n
Public Function <\/span>FehlerAnalysieren()\r\n Dim <\/span>cnn As <\/span>ADODB.Connection\r\n Dim <\/span>strConnection As String<\/span>\r\n Dim <\/span>strSQL As String<\/span>\r\n Dim <\/span>objError As <\/span>ADODB.Error\r\n Set<\/span> cnn = New<\/span> ADODB.Connection\r\n strConnection = \"Provider=MSOLEDBSQL;Server=amvDesktop2023;Trusted_Connection=yes;Database=Anlagen\"\r\n strSQL = \"INSERT INTO tblAnlagen(AnlageID) VALUES(1)\"\r\n cnn.ConnectionString = strConnection\r\n cnn.Open\r\n On Error Resume Next<\/span>\r\n cnn.Execute strSQL\r\n Debug.Print<\/span> \"Err.Number: \" & Err.Number\r\n Debug.Print<\/span> \"Err.Description: \" & Err.Description\r\n If <\/span>Not<\/span> Err.Number = 0 Then<\/span>\r\n For Each objError In cnn.Errors\r\n With<\/span> objError\r\n Debug.Print<\/span> \"Number: \" & .Number\r\n Debug.Print<\/span> \"Description: \" & .Description\r\n Debug.Print<\/span> \"NativeError: \" & .NativeError\r\n Debug.Print<\/span> \"Source: \" & .Source\r\n Debug.Print<\/span> \"SQLState: \" & .SQLState\r\n End With<\/span>\r\n Next<\/span> objError\r\n End If<\/span>\r\n cnn.Close\r\nEnd Function<\/span><\/pre>\nListing 2: Beispiel für einen SQL Server-Fehler<\/span><\/b><\/p>\n
Bereits für Err.Number <\/b>und Err.Description <\/b>erhalten wir diese Meldung:<\/p>\n
Err.Number: -2147217873\r\nErr.Description: Ein expliziter Wert für die Identitätsspalte kann nicht in der tblAnlagen-Tabelle eingefügt werden, wenn IDENTITY_INSERT auf OFF festgelegt ist.<\/pre>\n
Die Ausgabe des Fehlers der Errors<\/b>-Auflistung des Connection<\/b>-Objekts liefert folgende Informationen:<\/p>\n
Number: -2147217873\r\nDescription: Ein expliziter Wert für die Identitätsspalte kann nicht in der tblAnlagen-Tabelle eingefügt werden, wenn IDENTITY_INSERT auf OFF festgelegt ist.\r\nNativeError: 544\r\nSource: Microsoft OLE DB Driver for SQL Server\r\nSQLState: 23000<\/pre>\n
Unter Number <\/b>und Description <\/b>erhalten wir die gleichen Informationen wir über das Err<\/b>-Objekt.<\/p>\n
Mit NativeError <\/b>erhalten wir die SQL Server-interne Fehlernummer. Alle Fehlernummern und Fehlerbeschreibungen des SQL Servers in deutscher Sprache können wir uns übrigens mit der folgenden Anweisung, abgesetzt im SQL Server Management Studio, anzeigen lassen:<\/p>\n
SELECT * FROM sys.messages WHERE language_id = 1031;<\/pre>\n
Source <\/b>liefert die Fehlerquelle, in diesem Fall den Treiber, der hinter dem Provider MSOLEDBSQL <\/b>steckt. Und SQLState <\/b>liefert einen Zahlenwert, der wiederum einen ODBC-Fehlercode enthält. Diese Fehlercodes können wir beispielsweise auf der folgende Seite nachlesen:<\/p>\n
https:\/\/learn.microsoft.com\/en-us\/sql\/odbc\/reference\/appendixes\/appendix-a-odbc-error-codes?view=sql-server-ver15<\/pre>\n
Anderenfalls sollten diese unter dem Schlüsselwort ODBC Error Codes <\/b>zu finden sein.<\/p>\n
Für den Zahlencode 23000 <\/b>finden wir hier beispielsweise die Information Integrity constraint violation<\/b>.<\/p>\n
Benutzerdefinierte Fehler in gespeicherten Prozeduren<\/h2>\n
Um das nächste Beispiel sowohl mit DAO als auch mit ADODB nachvollziehen zu können, legen wir eine gespeicherte Prozedur in einer SQL Server-Datenbank an, die wie in Listing 3 aussieht.<\/p>\n
CREATE PROCEDURE Beispielfehlerprozedur_EinFehler\r\nAS \r\nBEGIN \r\n SET NOCOUNT ON; \r\n BEGIN TRY \r\n -- Ein Fehler wird absichtlich erzeugt (Division durch Null)\r\n DECLARE @x INT = 1 \/ 0; \r\n END TRY \r\n BEGIN CATCH \r\n -- Fehlerinformationen abrufen\r\n DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE(); \r\n DECLARE @ErrorSeverity INT = ERROR_SEVERITY(); \r\n DECLARE @ErrorState INT = ERROR_STATE(); \r\n -- Fehler zurückgeben\r\n RAISERROR(@ErrorMessage, @ErrorSeverity, @ErrorState); \r\n END CATCH \r\nEND;<\/pre>\n
Listing 3: Erzeugen eines Fehlers in einer gespeicherten Prozedur<\/span><\/b><\/p>\n
Die CREATE PROCEDURE<\/b>-Anweisung verwendet die TRY…CATCH<\/b>-Struktur von T-SQL. Im TRY<\/b>-Block, der mit BEGIN TRY <\/b>eingeleitet wird, weisen wir einer Variablen das Ergebnis einer Berechnung zu, die durch das Teilen von 1 <\/b>durch 0 <\/b>einen Fehler auslöst.<\/p>\n
Im CATCH<\/b>-Block deklarieren wir die drei Variablen @ErrorMessage<\/b>, @ErrorSeverity <\/b>und @ErrorState<\/b> und weisen diesen die Ergebnisse der Funktionen ERROR_MESSAGE()<\/b>, ERROR_SEVERITY() <\/b>und ERROR_STATE() <\/b>zu.<\/p>\n
Schließlich rufen wir die RAISEERROR<\/b>-Methode auf und übergeben dieser die drei zuvor festgelegten Variablen als Parameter. Durch das Ausführen der CREATE PROCEDURE<\/b>-Anweisung wird die gespeicherte Prozedur erstellt.<\/p>\n
Dann rufen wir diese gespeicherte Prozedur mit der folgenden Anweisung auf:<\/p>\n
EXEC Beispielfehlerprozedur_EinFehler<\/pre>\n
Damit erhalten wir eine Fehlermeldung, die wie eine herkömmlich ausgelöste Fehlermeldung aussieht (siehe Bild 2).<\/p>\n
![\"Ausführen](\"..\/fileadmin\/_temp_\/2024_06\/pic_451_001.png\")
<\/p>\nBild 2: Ausführen einer SQL Server-Abfrage im SQL Server Management Studio<\/span><\/b><\/p>\n
Fehler aus gespeicherter Prozedur mit VBA\/DAO auswerten<\/h2>\n
Nun wollen wir die gespeicherte Prozedur per DAO über VBA aufrufen und den Fehler auslösen und behandeln (siehe Listing 4). Dazu deaktivierten wir zunächst die eingebaute Fehlerbehandlung mit On Error Resume Next<\/b>. Dann referenzieren wir das aktuelle Database<\/b>-Objekt mit db <\/b>und erstellen mit der CreateQueryDef<\/b>-Methode eine neue temporäre Abfrage.<\/p>\n
Public Sub <\/span>DAO_TestError()\r\n On Error Resume Next<\/span> '' Fehlerbehandlung aktivieren\r\n \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 \r\n '' Gespeicherte Prozedur ausführen\r\n Set<\/span> qdf = db.CreateQueryDef(\"\")\r\n qdf.Connect = \"ODBC;DRIVER={ODBC Driver 17 for SQL Server};SERVER=amvDesktop2023;DATABASE=Anlagen;\" _\r\n & \"Trusted_Connection=Yes;\"\r\n qdf.SQL = \"EXEC Beispielfehlerprozedur_EinFehler\" '' Prozedur aufrufen\r\n qdf.ReturnsRecords = False<\/span>\r\n qdf.Execute\r\n \r\n '' Fehler abfangen\r\n If <\/span>Not<\/span> Err.Number = 0 Then<\/span>\r\n MsgBox<\/span> \"DAO-Fehler: \" & Err.Number & vbCrLf<\/span> & Err.Description, vbCr<\/span>itical, \"Fehler abgefangen\"\r\n Err.Clear\r\n End If<\/span>\r\n Set<\/span> qdf = Nothing\r\n Set<\/span> db = Nothing\r\nEnd Sub<\/span><\/pre>\nListing 4: Testen der gespeicherten Prozedur<\/span><\/b><\/p>\n
Der Connect<\/b>-Eigenschaft des QueryDef<\/b>-Objekts füllen wir mit einer Verbindungszeichenfolge für unsere Beispieldatenbank. Dann weisen wir der SQL-Eigenschaft den Aufruf unserer gespeicherten Prozedur zu. Die Eigenschaft ReturnsRecords <\/b>stellen wir auf False <\/b>ein und führen die Abfrage schließlich mit dem Execute<\/b>-Befehl aus. Wenn Err.Number <\/b>danach nicht den Wert 0 <\/b>enthält, also ein Fehler aufgetreten ist, wollen wir Err.Number <\/b>und Err.Description <\/b>in einer Meldung ausgeben. Hier erhalten wir nach dem Ausführen der Prozedur den Fehler mit der Nummer 3146 <\/b>und der Beschreibung ODBC-Aufruf fehlgeschlagen<\/b>.<\/p>\n
Hier sehen wir also erst einmal nicht die Meldung, die wir eigentlich vom SQL Server aus übergeben wollten. Das liegt, wie weiter oben erläutert, daran, dass immer nur die Standardmeldung ausgegeben wird. Wir ersetzen nun den Teil, der den Fehler ausgibt, durch die folgenden Anweisungen:<\/p>\n
If <\/span>Err.Number <> 0 Then<\/span>\r\n Dim <\/span>intFehler As Integer<\/span>\r\n Dim <\/span>objError As <\/span>DAO.Error\r\n For intFehler = 0 To DAO.Errors.Count - 1\r\n Set<\/span> objError = DAO.Errors(intFehler)\r\n Debug.Print<\/span> intFehler, objError.Number, _\r\n objError.Description, objError.Source\r\n Next<\/span> intFehler\r\nEnd If<\/span><\/pre>\nFühren wir die Prozedur nun erneut aus, erhalten wir das Ergebnis aus Bild 3 im Direktbereich. Hier sehen wir nun den Fehler, dessen Parameter wir im T-SQL-Skript festgelegt haben.<\/p>\n
![\"Alle](\"..\/fileadmin\/_temp_\/2024_06\/pic_451_002.png\")
<\/p>\nBild 3: Alle Fehler im Direktbereich<\/span><\/b><\/p>\n
Fehler aus gespeicherter Prozedur mit VBA\/ADODB auswerten<\/h2>\n
Nun schauen wir uns an, welche Fehlerinformationen die gleiche Prozedur unter Verwendung von ADODB hervorbringt. Dazu verwenden wir die Prozedur aus Listing 5.<\/p>\n
Public Sub <\/span>ADO_TestError()\r\n On Error Resume Next<\/span> '' Fehlerbehandlung aktivieren\r\n Dim <\/span>cnn As <\/span>ADODB.Connection\r\n Dim <\/span>cmd As <\/span>ADODB.Command\r\n Dim <\/span>objError As <\/span>ADODB.Error\r\n Dim <\/span>intFehler As Integer<\/span>\r\n '' Verbindung zu SQL Server herstellen\r\n Set<\/span> cnn = CreateObject(\"ADODB.Connection\")\r\n cnn.ConnectionString = \"Provider=MSOLEDBSQL;Data Source=amvDesktop2023;Initial Catalog=Anlagen;\" _\r\n & \"Integrated Security=SSPI;\"\r\n cnn.Open\r\n \r\n '' SQL-Befehl vorbereiten\r\n Set<\/span> cmd = CreateObject(\"ADODB.Command\")\r\n Set<\/span> cmd.ActiveConnection = cnn\r\n cmd.CommandText = \"EXEC Beispielfehlerprozedur_EinFehler\" '' Prozedur aufrufen\r\n cmd.CommandType = adCmdText '' (Optional, verbessert Performance)\r\n \r\n '' Prozedur ausführen\r\n cmd.Execute\r\n '' Fehlerbehandlung\r\n If <\/span>Not<\/span> Err.Number = 0 Then<\/span>\r\n Debug.Print<\/span> Err.Number, Err.Description, Err.Source\r\n For intFehler = 0 To cnn.Errors.Count - 1\r\n Set<\/span> objError = cnn.Errors(intFehler)\r\n Debug.Print<\/span> intFehler, objError.Number, objError.Description, objError.Source, objError.NativeError, _\r\n objError.SQLState\r\n Next<\/span> intFehler\r\n cnn.Errors.Clear\r\n End If<\/span>\r\n '' Aufräumen\r\n cnn.Close\r\n Set<\/span> cmd = Nothing\r\n Set<\/span> cnn = Nothing\r\nEnd Sub<\/span><\/pre>\nListing 5: Fehler ausgeben mit ADODB<\/span><\/b><\/p>\n
Hier definieren wir drei Variablen für das Connection<\/b>– und das Command<\/b>-Objekt sowie das Error<\/b>-Objekt. Wir erstellen eine Verbindung zur Datenbank und öffnen diese mit der Open<\/b>-Methode.<\/p>\n
Dann erstellen wir ein Command<\/b>-Objekt und weisen diesem die Verbindung aus cnn <\/b>zu. Als CommandText <\/b>legen wir den Aufruf der gespeicherten Prozedur fest. Als CommandType <\/b>nutzen wir die Konstante acCmdText<\/b>. Schließlich führen wir die gespeicherten Prozedur mit der Execute<\/b>-Methode des Command<\/b>-Objekts aus.<\/p>\n
Auch hier prüfen wir wieder, ob Err.Number <\/b>einen Wert ungleich 0 <\/b>aufweist. Dann geben wir als Erstes den Fehler aus, wie wir es auch im ersten Beispiel erledigt haben:<\/p>\n
Debug.Print<\/span> Err.Number, Err.Description, Err.Source<\/pre>\nDies liefert:<\/p>\n
-2147217900 Fehler aufgrund einer Division durch Null. Microsoft OLE DB Driver for SQL Server<\/pre>\n
Nun geben wir noch die Fehler aus, die in der Errors<\/b>-Auflistung von ADODB aufgelaufen sind.<\/p>\n
Hier erhalten wir:<\/p>\n
0 \r\n-2147217900 \r\nFehler aufgrund einer Division durch Null.\r\nMicrosoft OLE DB Driver for SQL Server\r\n50000\r\n42000<\/pre>\n
Die ersten Daten entsprechen denen, die uns auch das Err<\/b>-Objekt liefert. Die letzten beiden sind die Werte für NativeError <\/b>und SQLState<\/b>, die wir wiederum individuell auswerten können. Die wichtigste Erkenntnis ist aber: Während uns die Errors<\/b>-Auflistung der DAO-Klasse und in diesem Fall zwei Fehler liefert, nämlich den generischen VBA-Fehler und den speziellen SQL Server-Fehler, erhalten wir bei ADODB nicht den VBA-Fehler, sondern nur den SQL Server-Fehler.<\/p>\n
Nutzen der Errors-Auflistungen bei mehreren Fehlern<\/h2>\n
Aber benötigen wir dann die Errors<\/b>-Auflistung der ADODB-Klasse überhaupt? Wenn wir ohnehin nur einen Fehler erhalten?<\/p>\n
Das untersuchen wir nun. Zumindest, wenn die gespeicherte Prozedur auch einmal mehr als einen Fehler auslösen kann, sollten wir diese Fehler sowohl mit DAO als auch mit ADODB abrufen können. Wir haben in eine solche Prozedur nachgestellt (siehe Listing 6). Hier verwenden wir als ersten Fehler die bereits von oben bekannte Division durch 0. Danach nutzen wir eine weitere Anweisung, die einen Fehler auslöst – in diesem Fall durch den versuchten Zugriff auf eine Tabelle, die im Beispiel nicht existiert.<\/p>\n
CREATE PROCEDURE Beispielfehlerprozedur_ZweiFehler \r\nAS \r\nBEGIN \r\n SET NOCOUNT ON; \r\n BEGIN TRY \r\n -- 1. Fehler: Division durch Null\r\n DECLARE @x INT = 1 \/ 0; \r\n END TRY \r\n BEGIN CATCH \r\n -- Fehlerdetails erfassen\r\n DECLARE @ErrorMessage1 NVARCHAR(4000) = ERROR_MESSAGE(); \r\n DECLARE @ErrorSeverity1 INT = ERROR_SEVERITY(); \r\n DECLARE @ErrorState1 INT = ERROR_STATE(); \r\n -- Fehler mit RAISEERROR weitergeben\r\n RAISERROR(@ErrorMessage1, @ErrorSeverity1, @ErrorState1); \r\n END CATCH \r\n BEGIN TRY \r\n -- 2. Fehler: Tabelle existiert nicht\r\n INSERT INTO NichtExistiert (ID) VALUES (1); \r\n END TRY \r\n BEGIN CATCH \r\n -- Fehlerdetails erfassen\r\n DECLARE @ErrorMessage2 NVARCHAR(4000) = ERROR_MESSAGE(); \r\n DECLARE @ErrorSeverity2 INT = ERROR_SEVERITY(); \r\n DECLARE @ErrorState2 INT = ERROR_STATE(); \r\n -- Fehler mit RAISEERROR weitergeben\r\n RAISERROR(@ErrorMessage2, @ErrorSeverity2, @ErrorState2); \r\n END CATCH \r\nEND;<\/pre>\n
Listing 6: Gespeicherte Prozedur mit zwei Fehlern<\/span><\/b><\/p>\n
Wenn wir diese gespeicherte Prozedur im SQL Server Management Studio auslösen, erhalten wir die beiden Meldungen aus Bild 4.<\/p>\n
![\"Zwei](\"..\/fileadmin\/_temp_\/2024_06\/pic_451_003.png\")
<\/p>\nBild 4: Zwei Fehler in einer gespeicherten Prozedur im SQL Server<\/span><\/b><\/p>\n
Auch beim Aufrufen dieser gespeicherten Prozedur per DAO von VBA aus erhalten wir alle erwarteten Fehlermeldungen (siehe Bild 5).<\/p>\n
![\"Drei](\"..\/fileadmin\/_temp_\/2024_06\/pic_451_004.png\")
<\/p>\nBild 5: Drei Fehler beim Aufruf der gespeicherten Prozedur per DAO<\/span><\/b><\/p>\n
Danach passen wir unsere ADODB-Beispielprozedur auf die neue gespeicherte Prozedur an. Das Ergebnis überrascht ein wenig: Wir erhalten nur die erste Fehlermeldung zurück (siehe Bild 6).<\/p>\n
![\"Drei](\"..\/fileadmin\/_temp_\/2024_06\/pic_451_005.png\")
<\/p>\nBild 6: Drei Fehler beim Aufruf der gespeicherten Prozedur per ADODB<\/span><\/b><\/p>\n
Wozu dient dann aber die Errors<\/b>-Auflistung? Diese funktioniert schlicht in diesem Fall nicht, wo wir über einen Provider auf die Datenbank zugreifen und nicht per ODBC. Damit wir alle Fehler zurückerhalten, müssen wir also die Verbindungszeichenfolge ändern:<\/p>\n
conn.ConnectionString = “DRIVER={ODBC Driver 17 for SQL Server};SERVER=amvDesktop2023;DATABASE=Anlagen;Trusted_Connection=Yes;”<\/p>\n
Damit erhalten wir nun alle Fehlermeldungen. Wenn man also alle Fehlermeldungen erhalten möchte, muss man ODBC verwenden. Das geht in einigen Fällen zu Lasten der Performance.<\/p>\n
Zusammenfassung und Ausblick<\/h2>\n
Wenn man per VBA und DAO oder ADODB auf die Daten eines SQL Servers zugreifen möchte, kann es zu verschiedenen Problemen kommen.<\/p>\n
Dieser Artikel zeigt, wie man die Fehlerinformationen vom SQL Server holt und auswerten kann.<\/p>\n
Downloads zu diesem Beitrag<\/h2>\n
Enthaltene Beispieldateien:<\/p>\n
FehlerbehandlungFuerSQLServerInDAOUndADODB.accdb<\/p>\n
- SQLState<\/b>: Gibt den SQL-Fehlercode im standardisierten 5-stelligen Zeichenformat zurück. Diese Codes folgen dem SQL-92-Standard und sind von der Datenbank unabhängig.<\/li>\n<\/ul>\n
- Number<\/b><\/li>\n
- Raise<\/b>: Erzeugt einen benutzerdefinierten Fehler mit einer bestimmten Fehlernummer.<\/li>\n<\/ul>\n