MS-Office-Forum
Google
   

Zurück   MS-Office-Forum > Microsoft Access & Datenbanken > Microsoft Access
Registrieren Forum Hilfe Alle Foren als gelesen markieren

Banner und Co.

Antworten
Ads Der Renner, 11 Entwicklertools für Access, Tipps & Trick und offene Datenbanken zum einzigartigen Preis.
Themen-Optionen Ansicht
Alt 17.06.2017, 12:25   #1
PawelPopolski
MOF Profi
MOF Profi
Standard Acc2013 - Logfile für Prozeduren

Hallo,

es ist mir immer etwas unübersichtlich die Prozeduren mit Haltepunkten zu versehen. Gibt es etwas in der Art, das die durchlaufenen Prozeduren, nicht die einzelnen Befehle, aufzeichnet?

__________________

Gruß,
Pawel Popolski


Logik hat immer ein eindeutiges Ergebnis, folgt aber nicht zwingend einem eindeutigen Weg.
PawelPopolski ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 12:53   #2
CatboyJones
MOF User
MOF User
Standard

Ich glaube nicht. Du könntest Dir das selber bauen,
etwa von der Art:

Code:

Public Const ShowProcInfo As Boolean = True

Sub ProcName()
If ShowProcInfo Then Debug.Print "ProcName"
' ...
End Sub
Das müsstest Du halt in alle deine Procs reinschreiben
und die Ausgabe per Schalter steuern.

Gruss
Jones
CatboyJones ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 13:02   #3
Beaker s.a.
MOF Koryphäe
MOF Koryphäe
Standard

Hallo Pawel,
Nach dem gleichen Prinzip wie von Jones dargestellt, habe ich dafür eine Prozedur,
die mir Modul- und Prozedurname mit Zeitstempel in eine Tabelle schreibt.
Code:

Public Sub WriteLogFile( _
        ByVal MdlName As String, _
        ByVal ProcName As String)

    Dim strSQL As String
    strSQL = _
        "INSERT INTO EreignisLog (ModulName, ProzedurName) " _
      & "SELECT '" & MdlName & "', '" & ProcName

    CurrentDbC.Execute strSQL, dbFailOnError

End Sub
gruss ekkehard

__________________

--
S.M.I.²L.E.
Beaker s.a. ist gerade online  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 14:31   #4
PawelPopolski
Threadstarter Threadstarter
MOF Profi
MOF Profi
Standard

Grandios!

Besten Dank!

Hier mein angepasster Code:
Code:

Public Sub WriteLogFile(ByVal MdlName As String, ByVal ProcName As String)
'Schreibt Modul- und Prozedurnamen mit Zeitstempel in tblEventLog

    Dim strSQL As String
    strSQL = _
        "INSERT INTO tblEventLog (ModulName, ProzedurName) " _
      & "SELECT '" & MdlName & "', '" & ProcName & "'"

    CurrentDb.Execute strSQL, dbFailOnError

End Sub

__________________

Gruß,
Pawel Popolski


Logik hat immer ein eindeutiges Ergebnis, folgt aber nicht zwingend einem eindeutigen Weg.
PawelPopolski ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 14:44   #5
sonic8
MOF Profi
MOF Profi
Standard

Zitat: von CatboyJones Beitrag anzeigen

Das müsstest Du halt in alle deine Procs reinschreiben
und die Ausgabe per Schalter steuern.

Das ist ein gängiger Lösungsansatz für das Problem. Ich verwende diesen auch mehr oder weniger häufig.

Aber eigentlich ist das ziemlicher Mist.
...man muss den Code immer manuell einfügen.
...er macht die eigentliche Logik der Prozedur unübersichtlicher.
...beides wird schlimmer, wenn man noch Parameter/Rückgabewerte der Prozeduren oder gar einzelne Schritte in der Prozedur protokollieren möchte.

Praxis-Exkurs:
Ich hatte gerade letzte Woche den Fall eines von mir nicht reproduzierbaren Fehlers, der aber von Benutzern konsistent gemeldet wurde. Zugriff auf die Live-Systeme der Benutzer war nicht möglich.

Mein Lösungsansatz war, ein ausführliches Logging in die betroffenen Prozeduren einzubauen und die Benutzer nach Auftreten des Fehlers um das Logfile zu bitten.
Dies hat letztendlich zum Erfolg geführt. - Aber um welchen Preis?
Die Ursache des Fehlers wurde erst dann klar, nachdem ich für jede Zeile des eigentlichen Programmcode einen Aufruf der Protokollfunktion mit dem aktuellen Zustand der Prozedur ergänzt hatte.

Der Fehler ist jetzt behoben. Aber die Protokollierungsaufrufe stehen noch im Code....
Dass das Log-Output tatsächlich in eine Datei geschrieben wird, kann ich ausschalten. Das ist kein Problem.
Aber die betroffenen Prozeduren sind im jetzigen Zustand komplett unlesbar.
Lösche ich den Protokollierungscode jetzt wieder raus? Dann kann ich ihn in einer vergleichbaren Situation wieder einfügen. Doppelte (oder X-fache) Arbeit.
(Meine Entscheidung dazu: Ja, ich lösche den Protokollierungscode wieder (fast) komplett. Lesbarkeit ist mir wichtiger, als die evtl. erforderliche Zusatzarbeit ihn bei Bedarf wieder einzufügen.)
Der Exkurs hat hoffentlich mein Problem mit dem Lösungsansatz verdeutlicht.

Besser wäre eine automatische Lösung. Ein Automatismus, der nach Bedarf Protokollfunktionalität zu Prozeduren ergänzen kann. Idealerweise konfigurierbar. Und das in einer Weise, dass die Protokollfunktionalität nicht Teil des normalen Programmcodes wird.

Ein genereller Lösungsansatz dafür ist Aspektorientierte Programmierung (AOP).

Einen konkreten Umsetzungsvorschlag für Access/VBA habe ich aber nicht.
Als eine vielleicht mögliche Idee, könnte man im Rahmen eines Build-Prozesses den Logging-Code nach konfigurierten Vorgaben automatisch mit einem Tool in den eigentlichen Programmcode injizieren. - Ein existierendes Tool für VBA ist mir aber dafür nicht bekannt.

(Wie) Seht ihr diese Problematik?
Hab ihr Lösungsideen dazu?
sonic8 ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 16:05   #6
Beaker s.a.
MOF Koryphäe
MOF Koryphäe
Standard

Hallo,

Zitat:

Aber eigentlich ist das ziemlicher Mist.

Ich denke, das hängt aber auch ein bisschen am "Skill"-Level. Für einen Nichtprofi
sollte das ausreichend sein.

Zitat:

...man muss den Code immer manuell einfügen.

Dabei helfen mir die MZTools.

Zitat:

...er macht die eigentliche Logik der Prozedur unübersichtlicher.

In dieser einfachen Form ist es ja nur eine Zeile im Prozedurkopf
Code:

If ShowProcInfo Then Call WriteLogFile(ModulName, ProcedurName)
Wobei die MZTools mir die Parameter sogar einsetzt.

Ansonsten hast du aus deiner Sicht wohl recht, kann da mit meinem "Skill"-Level aber
nicht mitreden.

gruss ekkehard

__________________

--
S.M.I.²L.E.
Beaker s.a. ist gerade online  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 19:43   #7
PawelPopolski
Threadstarter Threadstarter
MOF Profi
MOF Profi
Standard

Hallo,

ich muss hier noch einmal einhaken um sicherzustellen, dass ich nicht "ungeschickt" vorgehe.

Was mich zum grübeln gebracht hat ist Ekkehard's Anmerkung:
In dieser einfachen Form ist es ja nur eine Zeile im Prozedurkopf
Code:
If ShowProcInfo Then Call WriteLogFile(ModulName, ProcedurName)
Ich habe meinen o.g. Code in ein Modul gepackt und in den Ereignissen oder Prozeduren verankert, die protokolliert werden sollen. Dort rufe ich die Protokollierung direkt mit Call WriteLogFile(ModulName, ProcedurName) auf und trage Modulname und Procedurname händisch ein.

Mache ich mir da mehr Arbeit als nötig?

__________________

Gruß,
Pawel Popolski


Logik hat immer ein eindeutiges Ergebnis, folgt aber nicht zwingend einem eindeutigen Weg.
PawelPopolski ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 20:43   #8
Beaker s.a.
MOF Koryphäe
MOF Koryphäe
Standard

Hallo Pawel,
Ich präzisiere

Zitat:

In dieser einfachen Form ist es ja nur eine Zeile im Prozedurkopf jeder Prozedur die geloggt werden soll

gruss ekkehard

__________________

--
S.M.I.²L.E.
Beaker s.a. ist gerade online  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 17.06.2017, 22:14   #9
PawelPopolski
Threadstarter Threadstarter
MOF Profi
MOF Profi
Standard

Danke für die Präzisierung :-)

Ich dachte schon ich hätte da etwas absolut missverstanden.

__________________

Gruß,
Pawel Popolski


Logik hat immer ein eindeutiges Ergebnis, folgt aber nicht zwingend einem eindeutigen Weg.
PawelPopolski ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 19.06.2017, 10:19   #10
markusxy
MOF Koryphäe
MOF Koryphäe
Standard

@sonic8,
war es schlussendlich ein logischer Fehler?

Was ist mit dem vbWatchdog? Wäre mit dem Tool ein einfaches Switchen zu einer entsprechenden Protokollierung möglich? Habe persönlich mit vbWatchdog noch keine Erfahrung.

LG Markus
markusxy ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 19.06.2017, 13:06   #11
sonic8
MOF Profi
MOF Profi
Standard

Zitat: von markusxy Beitrag anzeigen

@sonic8,
war es schlussendlich ein logischer Fehler?

Ja, genau. Ein von einer externen API geliefertes Objekt hatte in Einzelfällen nicht den Zustand, den es meiner Erwartung nach hätte haben sollen.

Zitat: von markusxy Beitrag anzeigen

Was ist mit dem vbWatchdog? Wäre mit dem Tool ein einfaches Switchen zu einer entsprechenden Protokollierung möglich? Habe persönlich mit vbWatchdog noch keine Erfahrung.

Der vbWatchdog hätte wohl den Funktionsumfang, den ich mir wünschen würde. Allerdings ist der Trigger für die Protokollierung des vbWatchdog das Auftreten ein Runtime Error. - Damit wäre das Tool für eine generelle Protokollierung ungeeignet.
sonic8 ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 19.06.2017, 13:19   #12
markusxy
MOF Koryphäe
MOF Koryphäe
Standard

Zitat: von sonic8 Beitrag anzeigen

Ja, genau. Ein von einer externen API geliefertes Objekt hatte in Einzelfällen nicht den Zustand, den es meiner Erwartung nach hätte haben sollen.


Der vbWatchdog hätte wohl den Funktionsumfang, den ich mir wünschen würde. Allerdings ist der Trigger für die Protokollierung des vbWatchdog das Auftreten ein Runtime Error. - Damit wäre das Tool für eine generelle Protokollierung ungeeignet.

Na ja, man müsste das Objekt auf Konsistenz prüfen und einen Laufzeitfehler auslösen, damit der Watchdog aktiv wird. Aber ich vermute, dass man auf solche Fälle immer erst bei einem Problem beginnt entsprechende Auswertungen zu fahren. Die Frage ist nur, ob der Watchdog das Mittel der Wahl für Fehlerverarbeitung ist.

LG Markus
markusxy ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 19.06.2017, 13:38   #13
sonic8
MOF Profi
MOF Profi
Standard

Zitat: von markusxy Beitrag anzeigen

Na ja, man müsste das Objekt auf Konsistenz prüfen und einen Laufzeitfehler auslösen, damit der Watchdog aktiv wird.

Diese Idee hat Schwächen.
  1. Wenn ich alle (Konsistenz-)Probleme im Voraus kenne und darauf prüfen kann, brauche ich vermutlich niemals Logging zur Fehleranalyse.
  2. Fehleranalyse ist ja nur ein Einsatzbereich des Loggings.
    Vielleicht möchte ich das Output des Loggings verwenden, um die Performance der Anwendung zu analysieren und Bottlenecks zu identifizieren.
    Oder ich möchte analysieren, welche Benutzer(gruppen) welche Features wie häufig verwenden.
sonic8 ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 19.06.2017, 14:20   #14
ebs17
MOF Guru
MOF Guru
Standard

Ich verwende zu Loggen eine externe Textdatei. Eine solche kann auch ein ungeübterer User mir unmittelbar übersenden. Bei DB-Tabellen und nur vorhandener Runtime wäre das schon ein wenig aufwändiger.
In die Meldungszeile kann man dann überdies Beliebiges schreiben und somit vorher prüfen.
Code:

Public Sub Append2TextFile(ByVal Content As String, Optional ByVal TextFile As Variant)
    Dim FF As Long
    If IsMissing(TextFile) Then TextFile = CurrentProject.Path & "Log.txt"
    FF = FreeFile()
    Open TextFile For Append As FF
    Print #FF, Content
    Close #FF
End Sub
Zumindest das Entfernen der Aufrufzeile aus dem Programmcode ist per Suchen & Ersetzen oder eine gleichwertige Maßnahme eine einfache Maßnahme.

__________________

Ein freundliches Glück Auf!

Eberhard

Abfrageperformance ist kein Geheimnis
SQL ist leicht: {0}:{1}:{2}:{3}:{4}:{5}:{6}:{7}:{8}:{9}:{10}
Dein Dankeschön: DBWiki=>Spende

Geändert von ebs17 (19.06.2017 um 14:42 Uhr).
ebs17 ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Alt 19.06.2017, 18:22   #15
CatboyJones
MOF User
MOF User
Standard

Die Notwendigkeit den Code wieder zu bereinigen impliziert ja,
dass man sich den tatsächlichen Designmaster mit dem
Logging-Code verseucht. Es langt doch wenn man für
Testzwecke eine Logging-Version vom aktuellen DM
erzeugt und diese nach dem Test wieder verwirft.

Kann ja nicht so schwer sein, das zu automatisieren, ggf. als AddIn.
Man durchläuft in allen Modulen alle Prozeduren und fügt hinter jeder
zusammenhängenden Zeile eine neu Zeile ein, die den vorhergehenden
Zeileninhalt mit Zeitangaben loggt. (Zeit, Prozedur, Zeileninhalt)

Das Ganze ist natürlich ausbaufähig.
Den Dim-Zeilen kannst man die Variablen-Namen entnehmen und die
Inhalte bei Vorkommen in der Zeile ebenfalls ausgeben.

Gruss
Jones
CatboyJones ist offline  
verlinken auf Del.icio.us Diese Seite zu Mister Wong hinzufügen
Antworten Auf Beitrag antworten
Ads
Antworten


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Besucher: 1)
 
Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge anzufügen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

vB Code ist An.
Smileys sind An.
[IMG] Code ist An.
HTML-Code ist An.
Gehe zu


Alle Zeitangaben in WEZ +1. Es ist jetzt 18:12 Uhr.


Partner und Co.
Access-Paradies -Alles rund um die Datenbank Microsoft Access -Code -Programme-Tools -Tipps   Kostenlose Tipps & Tricks, Downloads und Programme   www.kulpa-online.com - Tipps - Tricks - Tutorials - Meinungen - Downloads uvm...   vb@rchiv · Willkommen in der Welt der VB Programmierung   Access-Garhammer - Hier finden Sie jede Menge Beispiel-Datenbanken zu Access und mehr ...   mcseboard.de   Die Top Seite für Excel-VBA-Makros uvm.

Powered by: vBulletin Version 3.6.2 (Deutsch)
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.

Copyright ©2000-2010 MS-Office-Forum. Alle Rechte vorbehalten.
Copyright ©Design: Manuela Kulpa ©Rechte: Günther Kramer
Eine Verwendung der Inhalte in anderen Publikationen, auch auszugsweise,
ist ohne ausdrückliche Zustimmung der Autoren nicht gestattet.
Beachten Sie bitte auch unsere Nutzungsbedingungen.