Office: (Office 2016) Laufzeitfehler 3022

Hallo zusammen,
kann ich diesen Laufzeitfehler (3022) unterdrücken und durch eine MsgBox ersetzen?
Den Code nehme ich zum übertragen eines Textfeldes (Tab1) in eine andere Textfeld (Tab2). Ist auch Funktionsfähig!

PHP:

         Private Sub Befehl284_Click()
Dim db As DAO.Database
Dim rs As DAO.Recordset

Set db = CurrentDb()
Set rs = db.OpenRecordset("tabAuswahlG_Gruppe", dbOpenDynaset)
rs.AddNew ' An dieser Stelle wird ein neuer Datensatz initiert
rs!Bereitschaftsgruppe = Me!Bereitschaftsgruppe ' Hier wird der Wert
übergeben
rs.Update  Hier wird der Datensatz erst geschrieben
rs.Close
Set rs = Nothing
db.Close
End Sub


:)

 

Hi,
so:

Code:

 

Hallo Isabell,

hier eine Variante für eine Fehlerbehandlung:
Code:

Ich habe mal die Variable DB herausgeworfen, weil das hier nicht unbedingt nötigt ist. Außerdem solltest du niemals ein Objekt mit Close schließen, welches du nicht selber geöffnet hast. Also db.close in deinem Beispiel sollte man so nicht machen! Es hätte gereicht, die Referenz einfach auf Nothing zu setzen, um klarzustellen, daß diese Referenz nicht mehr benötigt wird, was du aber auch nicht gemacht hast.

Gruß Ulrich

 

Danke euch zwei für die schnelle Hilfe!!!
Der Code von Ulrich funktioniert einwandfrei, danke!!
Bei der Ergänzung von Regina taucht der Fehler weiterhin auf, trotzdem ein Dankeschön!!

 

Hallo Isabell,,
...wenn man einen Fehler ausblendet ist schon klar, dass du keine Feetback davon bekommst.
Den Fehler kannst genauso in ReginaR ihrem Code unterdrücken und auch in deinem Code *wink.gif*
Somit könntest auch gleich "On Error Resume Next" schreiben, das hat die gleiche Wirkung.

PS: man sollte aber schon vorher dafür Sorge tragen, dass kein Fehler auftreten kann.

 

\@Alfred:
die Laufzeitfehlermeldung soll nicht unterdrückt, sondern durch eine eigene Meldung ersetzt werden. Mit "On Error Resume Next" hat das nichts zu tun.

Gruß Ulrich

 

Nein!
Einen Fehler sollte man untersuchen und vermeiden!!!
Ich habe mir bisher Deinen/Euren Code nich angeschaut.

Eine Fehler-Unterdrückung spiegelt immer eine falsche Programmierung wieder!

Hab diese Woche keine Zeit - schaue mir das aber danach gerne an.

 

Eben noch mal mit einem Auge drübergeschaut....

Das ist doch alles völliger Humbuk!

Erkläre mal genau, was Du machen willst - und von wo aus!

 

\@Ulrich,

also das ist mir auch klar, das machst du aber nicht...
Code:

Das was ReginaR zeigt ist doch ok!
Er verwendet jetzt deinen Code und es wird kein Fehler mehr angezeigt...
was ja auch logisch ist.

 

Hallo,
dann mach es doch so:
Code:

Da muss die Error Routine gar nicht angesprochen werden.
Gruß
Jo

 

Hallo,

@Alfred:
in der Fehlerbehandlung steht extra TODO. Ich gehe mal davon aus, daß Isabell duchauch in der Lage ist, eine entsprechende Ausgabe nach Ihren Wünschen dort einzufügen. Wie gesagt, von Fehlermeldung unterdrücken kann keine Rede sein.

@Jo:
Im Prinzip hast du natürlich Recht, wenn zunächst eine Fehlervermeidung versucht wird, was in deinem Beispiel auch klar wird. Aber nicht immer ist das so gewünscht, z.B. wenn der Umstand eher selten auftritt, die Tabellen viele Datensätze enthalten, die Netzanbindung langsam ist usw. Dann kann ein FindFirst durchaus "teuer" werden und die andere Lösung mit einer Fehlerbehandlung wird interessant und ist genauso legitim. Hier muß abgewogen werden.

Interessanter wäre jetzt gewesen, die Fehlerbehandlung noch mit einem .CancelUpdate() zu ergänzen und die Aktualisierung des Recordsets wirklich sauber abzubrechen.

Gruß Ulrich

 

Ich bin auch dafür, Fehler zu vermeiden (fehlerfrei zu programmieren?!) statt Fehler zu behandeln und zu melden. Mein Auto freut sich darüber jedes Mal, wenn ich in die Garage einfahre.
Code:

Ein Filter ist effizienter als ein FindFirst und zuverlässig für eine Prüfung.
Ein gefilterte Abfrage in das Recordset zu laden ist effizienter als die ganze Tabelle zu laden. Bei Vorhandensein und Nutzung eines Index auf den Filter würde es tatsächlich stattfinden, dass nur die gefilterten Datensätze geladen werden.

Also prüfen und nur handeln, wenn kein Duplikat erzeugt wird.
Eine Fehlerbehandlung sollte sich UNERWARTETEN Fehlern widmen oder solchen Fehlern, die man zwar erwarten, aber technisch nicht prüfen kann.

Daneben kann ein versuchtes Neuanlegen eines Datensatzes mit Fehler trotzdem einen Autowert "verbrauchen" und somit eine "Lücke" hinterlassen. Wer das nicht alles als bleibenden Fehler werten wird ...

@Ulrich:
Eine Fehlerbehandlung, die nur genau einen Fehler berücksichtigt, ist hinsichtlich des Kontextes zu unerwarteten Fehlern etwas unglücklich.

 

\@Eberhard:
Manchmal sieht man den Wald vor lauter Bäumen nicht... aber du hast es auf den Punkt gebracht. *cool.gif*

Güße Ulrich