Supportnet / Forum / Datenbanken

1. Wie kann ich, wenn ich einen DS löschen möchte, die Nachfragemeldung ("sie beabsichtigen 1 Datensatz zu löschen...") abfangen? 2. Wie kann ich eine eigen Nachfrage (Ok / Abbrechen) erstellen?

zu 1.
In Datenbankmenü/Extra/Optionen in Register Bearbeiten/Suchen ---> Gruppe "Bestätigen"

zu 2.
Mit der MsgBox-Funktion. Genaueres kannst Du aus der VBA-Hilfe entnehmen.

CU
Carlo (:-))

P.S.

zu 1.
In VBA kannst Du die Warnmeldung an- bzw. abschalten mit:

DoCmd.SetWarnings False (bzw. True)

Carlo

Hallo CM,

die von Carlo genannten Lösungsvorschläge sind leider nicht ganz das Wahre. Bei Lösung Nr. 1 gibt es keine benutzerdefinierte Nachfrage und bei Lösung Nr. 2 kommst du in Teufels Küche, denn ALLE Fehler werden unterdrückt, auch diejenigen, die für den Softwareentwickler sehr wichtig sind für die Fehlersuche. DoCmd.SetWarnings False ist somit tabu. Nix für ungut, Carlo. ;-)

Deine Aufgabenstellung wird grundsätzlich auf die nachfolgende Weise realisiert, sofern Datensätze aus einem Formular und nicht direkt aus einer Tabelle gelöscht werden sollen:

Ein Formular besitzt das Ereignis "Vor Löschbestätigung". Das ist genau das richtige Ereignis, denn es erlaubt eine letzte Prüfung der Bedingungen, bevor ein Datensatz endgültig gelöscht wird bzw. löst auf Wunsch einen Abbruch der Löschung aus.

Private Sub Befehl0_Click()
   On Error Resume Next
   RunCommand acCmdDeleteRecord
   On Error GoTo 0
End Sub

Private Sub Form_BeforeDelConfirm(Cancel As Integer, Response As Integer)
   Dim intMsgResponse As Integer
   Dim strMsg As String
  
   Response = acDataErrContinue
   strMsg = "<benutzerdefinierte Frage>"
  
   intMsgResponse = MsgBox(strMsg, vbOKCancel + vbQuestion + vbDefaultButton2, "Löschung bestätigen")
   If intMsgResponse = vbCancel Then
      Cancel = True
   End If
End Sub

Das Ereignis "Befehl0_Click()" schaltet die Fehlerbehandlung vorübergehend aus und führt mit der Zeile  "RunCommand acCmdDeleteRecord" pauschal die Löschung durch. Die Abschaltung der Fehlerbehandlung ist notwendig, denn ein möglicher Abbruch der Löschung würde einen Laufzeitfehler auslösen. Anschliessend kann die Fehlerbehandlung ja wieder eingeschaltet werden.

Das Ereignis "Form_BeforeDelConfirm()" möchte zwei Parameter von dir gefüttert bekommen:

- Cancel: Liefere True zurück, wenn die Löschung verhindert werden soll.
- Response: Steuert das Access-eigene Verhalten nach Abarbeitung dieser Prozedur. Um Access-eigene Meldungen zu unterdrücken, muss hier die Konstante acDataErrContinue übergeben werden.

Dieses Ereignis ist auch der Platz, benutzerdefinierte Meldungen zu positionieren. Im obigen Beispiel musst du nur noch den Text "<benutzerdefinierte Frage>" ersetzen und schon ist das Ding einsatzbereit.

Gruss
PotzBlitz

bei Lösung Nr. 2 kommst du in Teufels Küche, denn ALLE Fehler werden unterdrückt, auch diejenigen, die für den Softwareentwickler sehr wichtig sind für die Fehlersuche. DoCmd.SetWarnings False ist somit tabu. Nix für ungut, Carlo. ;-)
-------------------------
Hallo Potzblitz,

das was Du sagst ist nicht ganz richtig. DoCmd.SetWarnings False ist schon dazu da, dass Du es auch benutzen kannst und zuweilen auch musst. Du darfst lediglich nicht vergessen *sofort* nach der einen Aktion, für die Du die Warnmeldungen ausschalten willst, diese auch wieder einzuschalten mit DoCmd.SetWarnings True und darfst dabei auch nicht übersehen, dass, falls Dein Code in eine Fehlerroutine reinspringen kann, dort auch DoCmd.SetWarnings True die erste Aktion ist.

Du kannst zwar die Access-Löschbestätigung abfangen mit acDataErrContinue, wobei ich Dein Beispiel nicht ausprobiert habe und die Befürchtung hege, dass Du mit
On Error Resume Next
RunCommand acCmdDeleteRecord
On Error GoTo 0
eine Endlosschleife produzierst im Fehlerfalle???

Aber wie willst Du bei einer Aktualisierungs- oder Anfügeabfrage die lästigen Accessmeldungen abschalten ohne
warnings false???

Gruß Marie

Hallo Marie,

wenn du DoCmd.SetWarnings verwendest, dann unterdrückst du Access-eigene Fehler, die du gemäss dem möglichen Programmablauf auch erwartest hättest, ganz klar. Aber was ist, wenn während des Programm-Ablaufs ein Fehler auftritt, von dem du dir nicht vorgestellt hast, dass er überhaupt auftreten könnte? Dann beginnt dein Programm sich merkwürdig zu verhalten und du wirst es nur sehr schwer haben, den Fehler zu finden. Selbst wenn die Meldungen für einen einzigen Befehl abgeschaltet werden, kann es wer weiss wieviele sonstige Meldungen geben, die den Fehlschlag der Aktion dokumentieren wollten. Stell dir vor, du hast eine Datenbank im Netzwerk liegen und führst eine Löschabfrage aus. Aufgrund eines Netzwerkfehlers (wg. Überlastung usw.) kann aber nicht gelöscht werden. Das wirst du mit deiner Variante nie erfahren und du wunderst dich, warum der Datensatz immer noch da ist. Beim nächsten Löschversuch wird es dir jedoch gelingen und du wunderst dich, warum es jetzt auf einmal geht. Grundsätzlich sollte für die Fehlerbehandlung ein OnError-Handler verwendet und *immer* auf DoCmd.SetWarnings verzichtet werden. Mit einem geeigneten Programmierstil gibts einfach keinen Grund, das jemals benutzen zu müssen, wirklich nicht.

In meinem Beispiel-Code tritt keine Endlosschleife auf. Hier wird "On Error Resume Next" nur dazu verwendet, um beim Abbruch der Löschung die Meldung "2501 Die Aktion RunCommand wurde abgebrochen." zu unterdrücken, die von RunCommand sonst angezeigt wird, wenn du auf "Abbrechen" geklickt hast. Da keine weiteren Programmzeilen mehr kommen, läuft die Ereignis-Prozedur ganz normal bei "Exit Sub" raus. Ausserdem würde der Abbruch auch das Programm zum Stillstand bringen. Weiterhin werden bei RunCommand keine sonstigen Access-Meldungen angezeigt, dass eine Löschung erfolgreich wäre oder ähnliches. Wenn du trotzdem irgendwelche Access-Bestätigungsmeldungen erhalten solltest, dass die Löschung erfolgreich wäre, dann entspricht das nicht der Standard-Konfiguration einer Access-Anwendung oder du verwendest einen Befehl bzw. Programmierstil, den ich jetzt nicht berücksichtigen konnte.

Um nochmals auf den ErrorHandler zurückzukommen. In meinem bisherigen Beispiel werden sämtliche Fehler unterdrückt, die beim Löschen auftreten können. Hier ging es hauptsächlich darum, die o.g. Meldung beim Abbruch zu unterdrücken; dass andere Fehler auftreten, ist kaum anzunehmen. Aber natürlich kann man das auch verfeinern, dann sähe das so aus:

Private Sub Befehl0_Click()
   On Error GoTo Err_Click
   RunCommand acCmdDeleteRecord
Exit_Click:
   Exit Sub
Err_Click:
   If Err.Number <> 2501 Then
      MsgBox Err.Description, vbCritical
   End If
End Sub

Hier wird ein ErrorHandler eingesetzt, der bei einem auftretenden Fehler zur Marke Err_Click springt. Dort wird geprüft, ob der Fehler 2501 (Die Aktion RunCommand wurde abgebrochen) aufgetreten ist, denn das hiesse ja, wir hätten auf Abbrechen geklickt. Ansonsten wird bei allen anderen Fehlern die anstehende Access-Meldung auf den Bildschirm gebracht.

Hmmm, da fällt mir gerade etwas ein. Verwendest du zur Ausführung "DoCmd.RunSQL"? Das würde auf jeden Fall eine Bestätigung der Aktualisierung bzw. Löschung auf den Bildschirm werfen, wie es auch bei der direkten Ausführung von Abfragen aus dem Datenbankfenster geschieht. In diesem Fall würde ich dir von der Benutzung dieses Befehls abraten und für die Löschung "RunCommand acCmdDeleteRecord" und für die Aktualisierung "CurrentDb.Execute <Abfrage/SQL>" empfehlen. Hier gibt es keine Meldungen ausser bei Fehlern, beide Zeilen werden "still" abgearbeitet.

Probier doch einfach mal mein Beispiel aus. Diese Lösch-Technik wird in allen Projekten eingesetzt, die unsere Softwareentwicklung verlassen. Ich versichere dir, sie funktionieren einwandfrei und zur völligen Zufriedenheit.

Wenn du noch weitere Fragen hast oder das Gespräch fortsetzen möchtest, dann schicke mir bitte eine eMail, denn ich kann nicht garantieren, dass ich diesen Beitrag nochmals aufrufe und deine Reaktion lesen werde. Ich bin jetzt auch nur wieder zufällig darübergestolpert. ;-)

Gruss
PotzBlitz

wenn du DoCmd.SetWarnings verwendest, dann unterdrückst du Access-eigene Fehler, die du gemäss dem möglichen Programmablauf auch erwartest hättest, ganz klar.
----------------
Nein, Potzblitz, ich mache das nur in einer Zeile mit dem ausführen einer SQL-Anweisung

Set dbs = CurrentDb
SQL = "DELETE DISTINCTROW blabla
DoCmd.SetWarnings False
dbs.Execute SQL, dbFailOnError
DoCmd.SetWarnings True
dbs.Close

Aber was ist, wenn während des Programm-Ablaufs ein Fehler auftritt, von dem du dir nicht vorgestellt hast, dass er überhaupt auftreten könnte?
-----------
Was soll in einer solchen Zeile für ein Fehler auftreten, den ich nicht abfangen kann? Ich schalt doch die fehlermeldung sofort wieder ein, der Fehler ist doch dann noch da und wird auch angezeigt. Es wird nur die Accessmeldung ausgeschaltet.
--------------
Dann beginnt dein Programm sich merkwürdig zu verhalten und du wirst es nur sehr schwer haben, den Fehler zu finden. Selbst wenn die Meldungen für einen einzigen Befehl abgeschaltet werden, kann es wer weiss wieviele sonstige Meldungen geben, die den Fehlschlag der Aktion dokumentieren wollten.
------------
Nö, durch dbFailOnError passiert gar nix weiter.
---------------
Stell dir vor, du hast eine Datenbank im Netzwerk liegen und führst eine Löschabfrage aus. Aufgrund eines Netzwerkfehlers (wg. Überlastung usw.) kann aber nicht gelöscht werden. Das wirst du mit deiner Variante nie erfahren und du wunderst dich, warum der Datensatz immer noch da ist. Beim nächsten Löschversuch wird es dir jedoch gelingen und du wunderst dich, warum es jetzt auf einmal geht.
---------------
Nein, es ist mir doch bei dbFailOnError ohnehin klar, dass die Löschabfrage nicht durchgeführt wurde, wenn ein Fehler auftritt, den kann ich doch sonstwie abfragen, da muss ich doch nicht die umständliche Routine mit Response = acDataErrContinue ausführen, die Dir eh bei Aktualisierungsabfragen nichts mehr bringt. Die blöden Meldungen sind doch gar keine Fehlermeldungen, ich schalt doch nur die ab.
----------------
Grundsätzlich sollte für die Fehlerbehandlung ein OnError-Handler verwendet und *immer* auf DoCmd.SetWarnings verzichtet werden.
-----------
Mit einem Error-Handler kann ich keine Meldung abfangen, die keine Fehlermeldung ist und die Sicherheitsabfrage beim Löschen oder Aktualisieren ist nu mal keine Fehlermeldung!!!!! Das ist doch lediglich eine Sicherheitsabfrage, ob Du die Änderungen wirklich durchführen willst, damit kommste nie und nimmer in einen ErrorHandler.
-----------
Mit einem geeigneten Programmierstil gibts einfach keinen Grund, das jemals benutzen zu müssen, wirklich nicht.
----------
Und wie bitte schaltest Du die Meldungen bei Aktualisierungsabfragen aus? Oder machst Du keine solchen? :-))
----------
Weiterhin werden bei RunCommand keine sonstigen Access-Meldungen angezeigt, dass eine Löschung erfolgreich wäre oder ähnliches. Wenn du trotzdem irgendwelche Access-Bestätigungsmeldungen erhalten solltest, dass die Löschung erfolgreich wäre, dann entspricht das nicht der Standard-Konfiguration einer Access-Anwendung oder du verwendest einen Befehl bzw. Programmierstil, den ich jetzt nicht berücksichtigen konnte.
------------
Kann ich mir denken, bist relativ neu in dem Job?? Leider gibt es in Access 95 kein RunCommand, das hat weder mit der Konfiguration von Access noch mit meinem Programmierstil zu tun. :-(((
---------------
Um nochmals auf den ErrorHandler zurückzukommen. In meinem bisherigen Beispiel werden sämtliche Fehler unterdrückt, die beim Löschen auftreten können. Hier ging es hauptsächlich darum, die o.g. Meldung beim Abbruch zu unterdrücken; dass andere Fehler auftreten, ist kaum anzunehmen.
-------------
Is ja interessant, vorher sprichst Du von allen möglichen Fehlern, die auftreten können und jetzt sagst Du, dass es kaum anzunehmen sei, dass andere Fehler auftreten?? Hab ich was falsch verstanden?
----------------------
Hmmm, da fällt mir gerade etwas ein. Verwendest du zur Ausführung "DoCmd.RunSQL"?
-----------
Nein, dbs.Execute SQL
----------
Das würde auf jeden Fall eine Bestätigung der Aktualisierung bzw. Löschung auf den Bildschirm werfen, wie es auch bei der direkten Ausführung von Abfragen aus dem Datenbankfenster geschieht. In diesem Fall würde ich dir von der Benutzung dieses Befehls abraten und für die Löschung "RunCommand acCmdDeleteRecord"
------------
Wire gesagt, runCommand-Befehle gibt es erst ab Access 97
------------
und für die Aktualisierung "CurrentDb.Execute <Abfrage/SQL>" empfehlen. Hier gibt es keine Meldungen ausser bei Fehlern, beide Zeilen werden "still" abgearbeitet.
-------------
Ich verwende immer DB.Execute, da hast DU Dich aber getäuscht, dass es da keine Meldungen gibt :-(((
------------
Probier doch einfach mal mein Beispiel aus. Diese Lösch-Technik wird in allen Projekten eingesetzt, die unsere Softwareentwicklung verlassen. Ich versichere dir, sie funktionieren einwandfrei und zur völligen Zufriedenheit.
----------------
Tja, ich glaub Dir ja, aber ich hatte auch noch niemals Probleme mit Warnings false und das ist IMO weniger umständlich.
-----------------
Wenn du noch weitere Fragen hast
-----------
Hatte ich Fragen an Dich??? Aber nett, dass Du so besorgt bist um mich. :-))
-----------
oder das Gespräch fortsetzen möchtest, dann schicke mir bitte eine eMail, denn ich kann nicht garantieren, dass ich diesen Beitrag nochmals aufrufe und deine Reaktion lesen werde. Ich bin jetzt auch nur wieder zufällig darübergestolpert. ;-)
------------
Schade :-(((

Trotzdem danke und Gruß

Marie

Hallo Marie,

> Set dbs = CurrentDb
> SQL = "DELETE DISTINCTROW blabla
> DoCmd.SetWarnings False
> dbs.Execute SQL, dbFailOnError
> DoCmd.SetWarnings True
> dbs.Close

> Was soll in einer solchen Zeile für ein Fehler auftreten, den ich nicht abfangen kann? Ich schalt doch die fehlermeldung sofort wieder ein, der Fehler ist doch dann noch da und wird auch angezeigt. Es wird nur die Accessmeldung ausgeschaltet.

Tja, das ist es ja gerade. Die Wege eines Programms sind unergründlich. Selbst bei der Ausführung dieser einzigen Zeile gibts Dutzende von möglichen Fehlerquellen.

> Nö, durch dbFailOnError passiert gar nix weiter.

Stimmt, leider auch kein Versuch, den Fehler zu korrigieren und den Programmablauf wieder fortzusetzen, wenn möglich.

> Nein, es ist mir doch bei dbFailOnError ohnehin klar, dass die Löschabfrage nicht durchgeführt wurde, wenn ein Fehler auftritt, den kann ich doch sonstwie abfragen, da muss ich doch nicht die umständliche Routine mit Response = acDataErrContinue ausführen, die Dir eh bei Aktualisierungsabfragen nichts mehr bringt. Die blöden Meldungen sind doch gar keine Fehlermeldungen, ich schalt doch nur die ab.

Selbstverständlich bringt das Zurückliefern von acDataErrContinue im Ereignis BeforDelConfirm() etwas, es unterdrückt Access-eigene Meldungen, um damit eigenen Meldungen den Vorrang zu überlassen. Hier meine ich insbesondere die Sicherheitsabfragen "xx Datensätze werden gelöscht/aktualisiert". Such doch mal in der Hilfe nach acDataErrContinue, dann findest du eine entsprechende Beschreibung.

> Mit einem Error-Handler kann ich keine Meldung abfangen, die keine Fehlermeldung ist und die Sicherheitsabfrage beim Löschen oder Aktualisieren ist nu mal keine Fehlermeldung!!!!! Das ist doch lediglich eine Sicherheitsabfrage, ob Du die Änderungen wirklich durchführen willst, damit kommste nie und nimmer in einen ErrorHandler.

Der ErrorHandler soll ja auch Fehler auffangen und keine Sicherheitsabfragen unterdrücken, die sowieso schon mit acDataErrContinue unterdrückt wurden. ;-)

> Und wie bitte schaltest Du die Meldungen bei Aktualisierungsabfragen aus? Oder machst Du keine solchen? :-))

Ok, nochmal: Es gibt keine Sicherheitsabfragen mit dbs.Execute! Ich habe in meinem Access sämtliche Sicherheitsabfragen in den Access-Optionen aktiviert und noch nie abgeschaltet. Trotzdem gibts diese Sicherheitsabfragen einfach nicht. Wenn ich Response = acDataErrContinue verwende, dann kommen solche Meldungen nicht, wenn ich diese Zeile aber auskommentieren würde, wären sie schwupps wieder da.

> Kann ich mir denken, bist relativ neu in dem Job?? Leider gibt es in Access 95 kein RunCommand, das hat weder mit der Konfiguration von Access noch mit meinem Programmierstil zu tun. :-(((

Nanana, du hattest nie gesagt, dass du mit Access 95 arbeitest. Das ist jetzt kein Grund, mir RunCommand um die Ohren zu hauen. RunCommand ist ab Access 97 der Nachfolger von DoCmd.DoMenuItem, was in Access 95 zu finden ist. In diesem Fall müsste die RunCommand-Zeile durch diese beiden Zeilen ersetzt werden (oder so ähnlich):

DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70
DoCmd.DoMenuItem acFormBar, acEditMenu, 6, , acMenuVer70

Mit dieser Modifikation solltest du mal mein Beispiel ausprobieren.

Irgendwo sind und bleiben wir alle immer neu in unserem Job und ich bin immer noch absolut bereit, etwas dazu zu lernen. Du solltest aber berücksichtigen, dass ich schon viele Berufsjahre Erfahrung mit Access-Datenbanken habe und bei ca. 30 z. Teil wirklich dicken Projekten beteiligt bzw. den Grossteil der Entwicklung übernommen habe. Das macht mit versch. weiteren Projekten in anderen Office-Programmen grob geschätzt 800.000 bis 1,2 Millionen Codezeilen bisher, inkl. einige Zigtausend Ausführungen der Execute-Methode ohne Sicherheitsabfragen. So ganz neu bin ich also nicht mehr in diesem Job. ;-)

Auch Access 95-Projekte waren dabei und auch dort gab es niemals(!!!) eine Sicherheitsabfrage bei der Execute-Methode des Datenbank-Objekts. Ich könnte mich wirklich nicht daran erinnern, ausserdem hätten wir bei allen Projekten damals unter Access 95 Hunderte von Sicherheitsabfragen auf dem Bildschirm gehabt. Und das hätte ich sehr wohl gemerkt, denn dann ich wäre im Dreieck gedopst. Die gab es aber nicht.

> Is ja interessant, vorher sprichst Du von allen möglichen Fehlern, die auftreten können und jetzt sagst Du, dass es kaum anzunehmen sei, dass andere Fehler auftreten?? Hab ich was falsch verstanden?

Nein, möglicherweise habe ich mich nur missverständlich ausgedrückt. Es gibt Fehler, die treten extrem selten auf, aber es ist nie auszuschliessen, DASS sie mal auftreten könnten. Und genau für diese Situationen sollte in jedem guten Programm ein ErrorHandler drin sein. Das Auftreten EINES sehr seltenen Fehlers, der nicht lokalisiert werden kann, kann eine sehr teure Angelegenheit werden, wenn du dir dann die Mühe machen darfst, diesen sporadisch auftretenden und nicht reproduzierbaren Fehler zu suchen. Ich verdiene mein Geld durch das Abliefern von funktionierenden Projekten und nicht durch das Suchen von Fehlern. Daher ist ErrorHandling ein wesentlicher Bestandteil der Qualitätssicherung und ab einem bestimmten Projektumfang auch absolut unerlässlich.

Wenn bei deinem obigen Programmbeispiel ein Fehler im SQL enthalten ist, sei es durch falsch formatierte oder fehlende Parameter oder was auch immer, dann würde dein Programm stehenbleiben, ganz radikal mitten im Programmablauf (es sei denn, du verwendest On Error Resume Next, was ich aber nicht hoffe). Nehmen wir weiterhin an, dass vor dem Stillstand schon 10 Aktionen durchgeführt wurden, die den Datenbestand bereits geändert haben, aber die restlichen und auch wichtigen Operationen nicht mehr abgeschlossen werden konnten, dann hast du einen "beschädigten" Datenbestand. Sowas darf nicht passieren. Ok, wir hätten ja eine Transaktion verwenden können, die die endgültige Durchführung der bisherigen Datensatzänderungen bis zum Commit verhindert, aber Transaktionen sind kein Ersatz für ein fehlendes ErrorHandling.

> Ich verwende immer DB.Execute, da hast DU Dich aber getäuscht, dass es da keine Meldungen gibt :-(((

Hmm, irgendwie reden wir aneinander vorbei.

> Hatte ich Fragen an Dich??? Aber nett, dass Du so besorgt bist um mich. :-))

Ja, in deinem ersten Beitrag hattest du zwei Fragen gestellt mit jeweils drei Fragezeichen. ;-)

Ich hatte übrigens dein Codebeispiel oben ausprobiert, obwohl ich vorher schon wusste, was dabei herauskommt: Eine "stille" Durchführung einer Aktionsabfrage, komplett ohne irgendwelche Sicherheitsabfragen. Und das jeweils mit UND ohne auskommentierte DoCmd.SetWarnings-Zeilen.

Fassen wir mal zusammen. Wir beide vertreten unseren jeweiligen Standpunkt bis zum letzten Augenblick, so wie es aussieht. Natürlich glaube ich dir, dass bei dir diese Sicherheitsabfragen auftauchen, jedoch habe ich dieses Verhalten während der Durchführung einer Aktionsabfrage aus dem Code heraus noch nicht erlebt, ausser ich verwende DoCmd.RunSQL. Ich wiederhole nochmals: In meinen Optionen sind immer sämtliche Bestätigungen aktiviert, einschl. Aktionsabfragen. Dies gilt übrigens für alle Computer und Access-Installationen, die ich jemals gesehen habe, sei es bei unseren Entwicklungsrechnern oder bei Kunden, die unsere Datenbanken verwenden, egal ob Access 95, 97 oder 2000. Daraus schliesse ich, dass mit der Konfiguration deines Access etwas nicht in Ordnung bzw. "anders als üblich" ist, ich kann aber nicht nachvollziehen, wo die Ursache für dieses Phänomen liegt.

Gruss
PotzBlitz

Sorry, dass ich Dir nun eine E-Mail schreiben musste. Aber meine lange Antwort hat irgendwo irgendein unerlaubtes Zeichen und konnte nicht abgeschickt werden.

Schade, denn es wäre sicher auch von allgemeinem Interesse gewesen weshalb wir hier so aneinander vorbeigeredet haben.

Nur kurz nochmal:

Du unterdrückst die Warnmeldungen nicht durch Execute, sondern durch acDataErrContinue. Ohne Response = acDataErrContinue bekommst Du auch bei DB.Execute die Warnmeldungen von Access, wie Du oben zwar selbst geschrieben hast, aber dann wohl genausowenig wie ich als Ursache unseres Missverständnisses erkannt hast.

Lieber Gruß und hoffe Dich mit meiner langen Mail nach so vielen Monaten nicht genervt zu haben, habe leider diese Antwort hier heute erst gelesen aufgrund Deines Hinweises.

Aber keine Sorge, ein ErrorHandling gibt es natürlich bei mir auch, das hat damit nichts zu tun :-)))

Trotzdem vielen dank nochmal für Deine Mühe und Deine Sorgen Dir meinen Kopf zu zerbrechen, lieb von Dir :-)))

Marie

• Abfangen eines nicht markierten Datensatzes im Listenfeld
• Typkonflikt abfangen.(Access 2003)
• Access 2000 - leere Abfrageergebnisse abfangen