SQL Statement Fehler Rückgabe in VBA
Hallo Foren User,
in einem SQL Statement lösche ich einen Datensatz aus einer Tabelle, die wiederum mit einer anderen verknüpft ist (Schlüssel).
Wenn dieser Eintrag nirgendwo referenziert ist, klappt das löschen ohne Probleme.
Jedoch wenn dieser auf eine andere Tabelle referenziert, dann müsste mir SQL einen Fehler zurückgeben.
Direkt auf dem SQL Server wird auch ein Fehler ausgegeben.
Kann man irgendwie mit OpenRecordset oder ähnlichem den SQL Fehler speichern?
Hierbei handelt es sich um Access 2007, VBA.
LG
AMStyles
in einem SQL Statement lösche ich einen Datensatz aus einer Tabelle, die wiederum mit einer anderen verknüpft ist (Schlüssel).
Wenn dieser Eintrag nirgendwo referenziert ist, klappt das löschen ohne Probleme.
Jedoch wenn dieser auf eine andere Tabelle referenziert, dann müsste mir SQL einen Fehler zurückgeben.
Direkt auf dem SQL Server wird auch ein Fehler ausgegeben.
CurrentDb.Execute "DELETE FROM PRJVERWTSTADMIN_PRJV_PROJEKT WHERE PROJEKT = 'Projekt1"
Hierbei handelt es sich um Access 2007, VBA.
LG
AMStyles
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 175449
Url: https://administrator.de/contentid/175449
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
21 Kommentare
Neuester Kommentar
Hi,
(Du schon wieder (; )
Die allgemeine Fehlerbehandlung mit dem Err-Objekt sollte doch ausreichen. Oder sehe ich hier was falsch?
(allgemeines Beispiel)
(Du schon wieder (; )
Die allgemeine Fehlerbehandlung mit dem Err-Objekt sollte doch ausreichen. Oder sehe ich hier was falsch?
On Error Resume Next
CurrentDb.Execute ("delete * from tabellle1")
If Err.Number <> 0 Then MsgBox Err.Description, , Err.Number
On Error GoTo 0
Was genau möchtest Du machen?
Das ist ja mit leichter Abänderung der o.g. Zeilen möglich. Und was soll außerdem noch passieren?
Allgemeine Fehlerbehandlung würde ich zu den Grundlagen von VBA zählen, auch wenn es aufgrund der Eigenschaften dieser Sprache häufig ignoriert wird.
den SQL Fehler speichern?
Das ist ja mit leichter Abänderung der o.g. Zeilen möglich. Und was soll außerdem noch passieren?
Allgemeine Fehlerbehandlung würde ich zu den Grundlagen von VBA zählen, auch wenn es aufgrund der Eigenschaften dieser Sprache häufig ignoriert wird.
ah, und wenn er nicht "ins IF springt" liegt es vermutlich daran das Du die On error resume next nicht ausführst.
Na ja, SlaintheMhath,
Noch eigentlicher wäre die sauberere Methode vorher mal einen Plan zu machen, wie der fachliche Zusammenhang und die Abhängigkeiten denn nun gestrickt werden sollen.
Grüße
Biber
Zitat von @SlainteMhath:
Also eigentlich wäre die saubere Methode eigentlich
1. Prüfen ob noch abhängige Datenseätze in anderen Tabelle vorhanden sind
2. Wenn nein => löschen
3. Wenn Ja => Fehler
Also eigentlich wäre die saubere Methode eigentlich
1. Prüfen ob noch abhängige Datenseätze in anderen Tabelle vorhanden sind
2. Wenn nein => löschen
3. Wenn Ja => Fehler
Noch eigentlicher wäre die sauberere Methode vorher mal einen Plan zu machen, wie der fachliche Zusammenhang und die Abhängigkeiten denn nun gestrickt werden sollen.
- entweder es sollen alle abhängigen Child-Sätze gelöscht werden, wenn in der PRJVERWTSTADMIN_PRJV_PROJEKT ein Projekt gelöscht werden soll. Dann ist die FK-Constraint ein "ON DELETE CASCADE" und es gibt keinen Fehler.
- oder es dürfen keine Sätze gelöscht werden, die Childsätze haben, weil die FK-Constraint "ON DELETE RESTRICT" ist. Dann kann ich, wenn ich doch weiss, dass es eh niemals nicht klappen kann, alle Sätze mit Childsätzen in einer passenden WHERE-Kalusel ausnehmen. Also ein LEFT JOIN mit der Childtabelle und "WHERE Childtab.Whatever IS NULL"
- oder aber es dürfen keine Sätze in der PRJVERWTSTADMIN_PRJV_PROJEKT physikalisch gelöscht werden, sondern werden stattdessen logisch gelöscht (in einem Feld INAKTIV oder DELETED markiert.). Dann kann die FK-Constraint sein wie sie will bzw. wie sie grad zufällig definiert wurde.
Grüße
Biber
Moin Biber
natürlich kann ich alles per FK Contraints in die DB zementieren. Allerdings ist dann immer noch das Problem, dem User eine sinnvolle Fehlermeldung auszugeben. I.d.R. hilft dem Anwender ein "Kann nicht gellöscht werden, weil...." mehr als ein "ODBC Call falied -- FK Contraint violated..."
Und
g,
Joerg
natürlich kann ich alles per FK Contraints in die DB zementieren. Allerdings ist dann immer noch das Problem, dem User eine sinnvolle Fehlermeldung auszugeben. I.d.R. hilft dem Anwender ein "Kann nicht gellöscht werden, weil...." mehr als ein "ODBC Call falied -- FK Contraint violated..."
Und
ON DELETE CASCADE
mag ich persönlich nicht, weil u:u. ein DELETE ganze Tabellen oder gar Datanbanken leer macht (Alles schon gesehen ) jaja ich weis, auch das lässt sich durch Planung verhindern.g,
Joerg
Moin SlaintheMhath,
ja nee, ich sehe es in diesem Fall nicht so, dass hier dem Endanwender eine sinnvolle Fehlermeldung helfen könnte.
Wie der viel zu früh verstummte Beitragsersteller geschrieben hat, ist der "Plan" doch, eine Batchverarbeitung, ein "DELETE... Where projekt ='XY'" auf Knopfdruck zu machen.
Dann kann ich sehr wohl im Konzept entscheiden, ob
Mein Kommentar oben sollte nur aussagen: "Menno, wenn jetzt beim Löschen eines Parent-Satzes erst über das Problem nachgedacht wird, dann ist es ein bisschen spät".
Grüße
Biber
ja nee, ich sehe es in diesem Fall nicht so, dass hier dem Endanwender eine sinnvolle Fehlermeldung helfen könnte.
Wie der viel zu früh verstummte Beitragsersteller geschrieben hat, ist der "Plan" doch, eine Batchverarbeitung, ein "DELETE... Where projekt ='XY'" auf Knopfdruck zu machen.
Dann kann ich sehr wohl im Konzept entscheiden, ob
- das DELETE-Knöpfchen überhaupt angeboten wird, wenn Childsätze vorhanden sind
- ob denn, wenn der befugte Anwender sagt "Dieses Projekt ist tot", auch alle Childsätze gelöscht werden, also die DB mit ON DELETE CASCADE hilft
- und die allerallerallerunkomfortabelste Lösung ist, dem Endanwender zu sagen "Hey, du musst vorher alle Childsätze löschen, sonst geht nix."
Mein Kommentar oben sollte nur aussagen: "Menno, wenn jetzt beim Löschen eines Parent-Satzes erst über das Problem nachgedacht wird, dann ist es ein bisschen spät".
Grüße
Biber
Die 3te Variante "und die allerallerallerunkomfortabelste Lösung ist, dem Endanwender zu sagen "Hey, du musst
vorher alle Childsätze löschen, sonst geht nix."" würde mir sehr helfen.
vorher alle Childsätze löschen, sonst geht nix."" würde mir sehr helfen.
Des is a Witz, oder?
Deine Planung scheint schwer verständlich. In den meisten Projektplanern ist es ja so, dass alle Childdatensätze eines Projekts 'automatisch' gelöscht werden, sobald das Projekt selber gelöscht wird -> Biber-Variante 2.
Es erschliesst sich nicht der Sinn, warum Du in diesem Fall eine Meldung ausgeben willst und was weiter passieren soll.....
Es erschliesst sich nicht der Sinn, warum Du in diesem Fall eine Meldung ausgeben willst und was weiter passieren soll.....
Dann die Löschweitergabe einrichten (Biber-2-Variante) und vor der Delete-Abfrage mittels einer Select-Abfrage bestimmen, ob Childdatensätze vorhanden sind.
Und vorher vielleicht doch noch mal überlegen ob man den User mit sowas wie "Childdatensätze" behelligen möchte oder ob nicht allgemein die Frage reicht: "Möchten Sie das Projekt wirklich löschen? Ja/Nein" - unabhängig davon ob Child- DS existieren oder nicht.
Gruß
Und vorher vielleicht doch noch mal überlegen ob man den User mit sowas wie "Childdatensätze" behelligen möchte oder ob nicht allgemein die Frage reicht: "Möchten Sie das Projekt wirklich löschen? Ja/Nein" - unabhängig davon ob Child- DS existieren oder nicht.
Gruß
Du musst nicht viel in VBA machen! Das Löschen der Child-DS übernimmt Dein Backend - sofern eingerichtet ("ON DELETE CASCADE")
und der VBA-Teil sieht dann ungefähr so aus:
und der VBA-Teil sieht dann ungefähr so aus:
If MsgBox("soll das Projekt gelöscht werden?", vbYesNo) = vbYes Then _
CurrentDb.Execute "DELETE FROM PRJVERWTSTADMIN_PRJV_PROJEKT WHERE PROJEKT = '" & strProjektName "'"