- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#31
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von Knobbi38 - Juli 14, 2025, 21:53:44Zitat von: Doming am Juli 14, 2025, 21:06:18Die lokale, boolsche Variable setze ich, weil ich im Nachgang noch mehrere Datensätze aus der Tabelle nutzen möchte, dazu muss nicht jedes Mal erneut das DCount losgeschickt werden.Wieso sollte man mehrmals DCount() aufrufen müssen? Alles gehört in einen IF THEN ELSE Zweig:
Code [Auswählen]
IF TabelleOK() then
' Todo:
ELSE
' Error:
END IF
Vielleicht kannst du mal deinen ganzen Code hier zeigen, sonst wird eine Hilfe schwierig.
Knobbi38
#32
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von PhilS - Juli 14, 2025, 21:20:44Zitat von: Doming am Juli 14, 2025, 21:06:18Das ganze Resume Next ist mir eigentlich zuwider, aber der ganze Rotz soll im Hintergrund ablaufen. Wenn Fehler auftreten sollen sie ins Protokoll, ansonsten möchte ich da keine Unterbrechungen bei den Anwendern.Ich zweifle ob auch dafür dein Ansatz mit Resume Next so geeignet ist.
Wenn in einem mehrstufigen Ablauf Fehler auftreten, erscheint es fragwürdig, ob es Sinn macht den Prozess fortzusetzen, wenn bereits Fehler aufgetreten sind.
#33
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von Doming - Juli 14, 2025, 21:06:18Die lokale, boolsche Variable setze ich, weil ich im Nachgang noch mehrere Datensätze aus der Tabelle nutzen möchte, dazu muss nicht jedes Mal erneut das DCount losgeschickt werden.
Das ganze Resume Next ist mir eigentlich zuwider, aber der ganze Rotz soll im Hintergrund ablaufen. Wenn Fehler auftreten sollen sie ins Protokoll, ansonsten möchte ich da keine Unterbrechungen bei den Anwendern.
Morgen kann ich wieder weiter rumprobieren...
Das ganze Resume Next ist mir eigentlich zuwider, aber der ganze Rotz soll im Hintergrund ablaufen. Wenn Fehler auftreten sollen sie ins Protokoll, ansonsten möchte ich da keine Unterbrechungen bei den Anwendern.
Morgen kann ich wieder weiter rumprobieren...
#34
Access Programmierung / Re: Suchen mit Barcode
Letzter Beitrag von MzKlMu - Juli 14, 2025, 18:35:43Hallo,
verknüpfe Hafo und Ufo zusätzlich über den Barcode, dann geht das automatisch.
verknüpfe Hafo und Ufo zusätzlich über den Barcode, dann geht das automatisch.
#35
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von PhilS - Juli 14, 2025, 18:33:47Zitat von: Doming am Juli 14, 2025, 15:05:24tblSAPDaten ist nicht vorhanden, also booltblOK ist False und die Meldung "nicht lesbar" wird ausgegeben.Dann schau dir mal genau an was in deinem hier nicht gezeigtem Code-Segment "..." passiert. M.M. muss dort erneut auf die nicht vorhandene SAP-Tabelle zugegriffen werden und dabei wird der neue Fehler ausgelöst.
Dann wird erneute eine Eingabe generiert, mit dem Fehler 3075 Tabelle nicht vorhanden, obwohl mit Err.Number vorher mit 0 angezeigt wird.
#36
Access Programmierung / Suchen mit Barcode
Letzter Beitrag von alfini - Juli 14, 2025, 17:49:13Hallo Forum,
Folgende Situation:
Hauptform. mit Fir_ID
Unterform. mit Fir_ID_F und noch mehrere Felder. Ein Feld ist als Barcode angelegt als Text.
Jetzt möchte ich nach Barcode im UFO suchen und den gefundenen DS anzeigen.
Das Suchfeld für den Barcode ist auf dem HF.
Es soll nur der DS im UFO angezeigt werden mit den Barcode.
Wie lässt sich das lösen?
Für eure Mühe bedanke ich mich im voraus.
Gruß alfini
Folgende Situation:
Hauptform. mit Fir_ID
Unterform. mit Fir_ID_F und noch mehrere Felder. Ein Feld ist als Barcode angelegt als Text.
Jetzt möchte ich nach Barcode im UFO suchen und den gefundenen DS anzeigen.
Das Suchfeld für den Barcode ist auf dem HF.
Es soll nur der DS im UFO angezeigt werden mit den Barcode.
Wie lässt sich das lösen?
Für eure Mühe bedanke ich mich im voraus.
Gruß alfini
#37
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von Knobbi38 - Juli 14, 2025, 17:23:17Hallo,
mehrere Errorhandler machen eine Sache nicht sicherer! Wenn du Errorhandler in TabelleOK() und SAPLesen() hast, was ja richtig ist, dann kannst du dir in der aufrufenden Sub den Errorhandler sparen, weil dort eigentlich der Rückgabewert ausgewertet werden sollte. Die Variable "BooltblOK" ist deshalb auch nicht notwendig.
Der Programmablauf sollte also nochmal etwas überarbeitet werden, SAPLesen() einen Rückgabewert liefern und den Errorhandler in der übergeordneten Sub entfernen. Du kannst dir den PAP ja mal als Nassi-Shneiderman Diagramm auf Papier kurz skizzieren, oft hilft das.
Gruß Knobbi38
PS:
Was genau möchtest du eigentlich mit TabelleOK() überprüfen?
mehrere Errorhandler machen eine Sache nicht sicherer! Wenn du Errorhandler in TabelleOK() und SAPLesen() hast, was ja richtig ist, dann kannst du dir in der aufrufenden Sub den Errorhandler sparen, weil dort eigentlich der Rückgabewert ausgewertet werden sollte. Die Variable "BooltblOK" ist deshalb auch nicht notwendig.
Der Programmablauf sollte also nochmal etwas überarbeitet werden, SAPLesen() einen Rückgabewert liefern und den Errorhandler in der übergeordneten Sub entfernen. Du kannst dir den PAP ja mal als Nassi-Shneiderman Diagramm auf Papier kurz skizzieren, oft hilft das.
Gruß Knobbi38
PS:
Was genau möchtest du eigentlich mit TabelleOK() überprüfen?
#38
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von Doming - Juli 14, 2025, 15:05:24Danke für die Ausführungen.
Mein aktuelles Problem ist folgendes: Offenbar ist letzte Nacht kein Datenexport aus SAP erfolgt, eine von mir genutzte Nachschlagetabelle funktioniert also nicht. Ein gute Gelegenheit, eine Ausnahme im Errorhandler einzubauen.
Mit dieser Funktion setze ich eine lokale Variable
tblSAPDaten ist nicht vorhanden, also booltblOK ist False und die Meldung "nicht lesbar" wird ausgegeben.
Dann wird erneute eine Eingabe generiert, mit dem Fehler 3075 Tabelle nicht vorhanden, obwohl mit Err.Number vorher mit 0 angezeigt wird. Eigentlich war der Fehler doch schon abgefrühstückt?
Mein aktuelles Problem ist folgendes: Offenbar ist letzte Nacht kein Datenexport aus SAP erfolgt, eine von mir genutzte Nachschlagetabelle funktioniert also nicht. Ein gute Gelegenheit, eine Ausnahme im Errorhandler einzubauen.
Code [Auswählen]
Public Function TabelleOK(Tabelle As String) As Boolean
On Error GoTo Fehler
Dim Menge
Menge = DCount("*", Tabelle)
TabelleOK = True
Ende:
Err.Clear
Exit Function
Fehler:
Resume Ende
End FunctionMit dieser Funktion setze ich eine lokale Variable
Code [Auswählen]
On Error Goto Fehler
BooltblOK = TabelleOK("tblSAPDaten")
If BooltblOK then
Eingabe "Importiere Daten aus SAP"
SAPLesen
Else
Eingabe "Tabelle tblSAPDaten ist nicht lesbar"
End if
...
Exit Sub
Fehler:
Eingabe "Fehler (" & Err.Number & ") Prozedur Ablauf:" & Err.Description
Resume Next
End Sub
'Eingabe' gibt dem Nutzer die aktuelle Aktion ausCode [Auswählen]
Public Sub Eingabe(Txt As String)
Debug.Print Err.Number
CurrentDb.Execute "INSERT INTO tbl_WartungsProtokoll(Zeit, Tat) VALUES (" _
& fncTimSQL(Now) & ", '" _
& Txt & "')"
Das hat jetzt folgenden Effekt:tblSAPDaten ist nicht vorhanden, also booltblOK ist False und die Meldung "nicht lesbar" wird ausgegeben.
Dann wird erneute eine Eingabe generiert, mit dem Fehler 3075 Tabelle nicht vorhanden, obwohl mit Err.Number vorher mit 0 angezeigt wird. Eigentlich war der Fehler doch schon abgefrühstückt?
#39
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von Knobbi38 - Juli 14, 2025, 15:00:56Hallo,
im Prinzip stimmt das schon, was Christian da mit den Errorhandlern beschrieben hat, nur
Hier mal ein paar weiter führende Links:
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/aa716196(v=vs.60)
http://www.cpearson.com/excel/errorhandling.htm
https://stackoverflow.com/questions/14158901/difference-between-on-error-goto-0-and-on-error-goto-1-vba
Gruß Knobbi38
im Prinzip stimmt das schon, was Christian da mit den Errorhandlern beschrieben hat, nur
Zitat von: Bitsqueezer am Juli 14, 2025, 13:52:35Err.Clear hebt natürlich jeden Fehler auf.Err.Clear löscht nur das Error-Objekt, setzt aber nicht den Errorhandler zurück! Err.Clear wird implizit auch bei
- Allen Arten von Resume-Anweisungen
- Exit Sub, Exit Function, Exit Property
- Einer On Error -Anweisung
Hier mal ein paar weiter führende Links:
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/aa716196(v=vs.60)
http://www.cpearson.com/excel/errorhandling.htm
https://stackoverflow.com/questions/14158901/difference-between-on-error-goto-0-and-on-error-goto-1-vba
Gruß Knobbi38
#40
Access Programmierung / Re: Wann stirbt die „Sprungmar...
Letzter Beitrag von Bitsqueezer - Juli 14, 2025, 13:52:35Hallo,
der Handler kann nur in der Prozedur, in der er ist, den Fehler behandeln.
Wenn es keinen gibt, ist die aufrufende Zeile in der übergeordneten Prozedur der Fehlerauslöser dort, auch wenn der Fehler innerhalb der aufrufenden Prozedur stattfand. Wenn es dort einen Fehlerhandler gibt, wird dieser angesprungen. Wenn nicht, den nächst höheren Aufrufer, und wenn es keinen mehr gibt, springt der Access-Debugger an.
Err.Clear hebt natürlich jeden Fehler auf.
Resume in allen Varianten auch.
Eine Fehlerzeile kann nur verwendet werden, wenn man auch Zeilennummern verwendet, das sollte man aber heutzutage nicht mehr machen, ist auch völlig unnötig.
Ich mache das so, daß ich Errorhandler immer mit MZTools einfüge, was den Vorgang stark vereinfacht.
Dazu hänge ich an den Errorhandler unten nach der letzten Zeile eine Zeile "Resume" an. Diese wird also nie ausgeführt.
Wenn ich den Fehler untersuchen will und im Fehlerhandler stoppe, kann ich dann den Programmzähler auf "Resume" springen lassen und diesen ausführen, dann springt er mir auf genau die Zeile, die den Fehler verursacht hat - ganz ohne Zeilennummern.
Gruß
Christian
der Handler kann nur in der Prozedur, in der er ist, den Fehler behandeln.
Wenn es keinen gibt, ist die aufrufende Zeile in der übergeordneten Prozedur der Fehlerauslöser dort, auch wenn der Fehler innerhalb der aufrufenden Prozedur stattfand. Wenn es dort einen Fehlerhandler gibt, wird dieser angesprungen. Wenn nicht, den nächst höheren Aufrufer, und wenn es keinen mehr gibt, springt der Access-Debugger an.
Err.Clear hebt natürlich jeden Fehler auf.
Resume in allen Varianten auch.
Eine Fehlerzeile kann nur verwendet werden, wenn man auch Zeilennummern verwendet, das sollte man aber heutzutage nicht mehr machen, ist auch völlig unnötig.
Ich mache das so, daß ich Errorhandler immer mit MZTools einfüge, was den Vorgang stark vereinfacht.
Dazu hänge ich an den Errorhandler unten nach der letzten Zeile eine Zeile "Resume" an. Diese wird also nie ausgeführt.
Wenn ich den Fehler untersuchen will und im Fehlerhandler stoppe, kann ich dann den Programmzähler auf "Resume" springen lassen und diesen ausführen, dann springt er mir auf genau die Zeile, die den Fehler verursacht hat - ganz ohne Zeilennummern.
Gruß
Christian