Log-Datei realisieren

[juergen]

Hallo zusammen,
(ich hoffe, dass meine nachfolgende Frage zu diesem Thread paßt und kein neuer Thread dafür erstellt werden braucht)

Wenn man nun die Größe der Protokolldatei festlegen will/muss, wie sollte man da am besten vorgehen?
Die Protokolldatei jedes mal in z.B. eine TStringList laden und wenn eine vorgegebene Größe erreicht ist, dann einfach einen festen "Block" (z.B. die ersten 20000 Zeilen) löschen?
Dann hätte man immer noch eine gewisse Historie.
(das wäre dann quasi eine selbst reorganisierende Datei)

Eine andere Möglichlkeit wäre noch, wenn die Protokolldatei die vorgegebene Größe erreicht hat, dann diese Datei einfach umzubenennen und die Protokollierung in eine neue und damit "leere" Protokolldatei fortzusetzen.

[marabu]

Hallo Jürgen,

ich würde an Hand von Erfahrungswerten ein Zeitintervall bestimmen, nach dessen Ablauf automatisch auf eine neue Protokolldatei umgestellt wird.

Grüße vom marabu

[juergen]

Hallo marabu,
so einfach?!
Ehrlich gesagt, an diese Variante hatte ich noch gar nicht gedacht.
Ich werde das bei mir jetzt auch genauso ändern, dass ein eigenen Ordner (Protokollierung) innerhalb der Anwendung angelegt wird.
Dann wird für jeden Monat eine Protokolldatei geschrieben.
Und dann noch einen "Protokoll-Viewer" basteln. Fertig ist's.

Danke und ein schönes Wochenende!

[himitsu]

also in meiner PHP-Version ist es so gelöst, das bei Erreichen einer maximalen Dateigröße die Datei bis zum Minimum(Dateigröße) alte Einträge entfernt werden.
(hab mir das so einfallen lassen, da in dem Projekt seltener Einträge vorgenommen werden und eh nur die Einträge der näheren Vergangenheit interesant sind)

und jedesmal die Datei komplett einzulesen wäre auch nicht grad optimal.
(verbraucht nur unnötig Resourcen und Zeit)

[Hansa]

Trotz der Einwände bleibe ich hier bei der Ausgangsfrage :

Zitat von Infect:

..ich möchte gerne eine Log-Datei realisieren, in die mehrere Programme (bzw. mehrere Instanzen desselben Programms) ihre Einträge machen. Wie realisiere ich so etwas am besten, ohne dass die Programme sich beim Hineinschreiben in die Datei in die Quere kommen?

Die Gefahr besteht bei Textdateien immer, dass in eine zum Lesen geöffnete Datei versucht wird, was reinzuschreiben. Kann bei DB kaum passieren, sofern die entsprechende Tabelle zumindest einen eindeutigen Primärschlüssel besitzt. Oder soll unnötig rumgeeiert werden ? Faxman hat die Problematik erkannt, sonst keiner.

[MatthiasR]

Zitat von Reinhard Kern:

EXCLUSIVE ist das entscheidende: ich habe es vorgeschlagen, hamamitsu hat damit eine ganze Beispielprozedur geschrieben und shmia hat eine Alternative mit TExclusiveFileStream vorgeschlagen, die intern das gleiche tut. Vielleicht sind wir ja blöd, aber immerhin sind wir schon zu dritt.

Da du nix verstanden hast, lässt du das entscheidende Statement mit fmShareExclusive einfach weg. So was nenne ich beratungsresistent.

Wenn du dich mal mit Dateien beschäftigen würdest, dann würdest du auch auf den Begriff "exklusiver Zugriff" stossen. Meine Meinung zum Thema: solange du diesen Punkt nicht verstanden hast, kannst du dein Problem nicht lösen - stattdessen auf Mutexe u.a. auszuweichen, ist Blödsinn, weil das das Problem nur anders einkleidet und dazu noch komplizierter ist als Datei-Zugriffe.

Natürlich hast du als Jungprogrammierer das Recht, alles anders zu sehen und alle Erkenntnisse der IT mit Verachtung zu strafen. Schon ein Konkurrent weniger.

Gruss Reinhard

Das mit dem exclusiven Öffnen der Log-Datei habe ich schon verstanden, jedoch bin ich davon ausgegangen, dass das bei Windows bei schreibenden Zugriffen automatisch so gesteuert wird. Und Append ist für meine Begriffe ja ein schreibender Zugriff. Diese Annahme wurde für mich dadurch bekräftigt, dass ein schreibendes Öffnen ein und derselben Datei mittels Append eben NICHT durch mehrere Programme gleichzeitig möglich ist, sondern in einer Exception endet. Auch ohne diese besagte Zeile!!! Das einzige, was ich daher von euch wissen wollte, ist, was das vorige setzten des FileMode genau bewirkt. Für mich ergeben sich zumindest bei mir KEINE sichtbaren Änderungen, wenn ich diese Zeile einfüge!!! Mein Programm verhält sich kein Stück anders, als wenn ich die Zeile weglasse. Deswegen wollte ich es genau wissen, was intern abgeht, bevor ich diese Zeile blindlings übernehme. Ich hoffe, du siehst es mir nach, dass ich Dinge lieber erstmal hinterfrage. Genauso bei shmias Klasse. Wenn ich selbst eine Lösung gefunden habe, die zwar womöglich nicht ganz so komfortabel ist, jedoch ihren Dienst verrichtet, auf meinem eigenen Mist gewachsen ist und ich daher auch 100%ig durchsteige, was da intern eigentlich abläuft, dann ziehe ich diese Lösung vor.

Also frage ich nochmal: was bewirkt die ZeileFileMode := fmOpenReadWrite or fmShareExclusive; genau? Was ist anders, wenn ich die Zeile einfach weglasse? Mein Programm verhält sich wie gesagt genauso...

[Hansa]

Zitat von Infect:

..dass ein schreibendes Öffnen ein und derselben Datei mittels Append eben NICHT durch mehrere Programme gleichzeitig möglich ist...

So ist es. Es geht um eine einzelne Datei. Noch nie in Word die Meldung gesehen : "Dokument von anderem Benutzer im Zugriff ! Schreibgeschützt öffnen ?" oder so ähnlich ? Genau das ist der Punkt. Natürlich kann ich das umgehen, indem ich das eine Word-Dokument verlasse (oder die Log-Datei schließe) und dann den vorher geänderten und abgespeicherten Text neu öffne und dann eben nicht schreibgeschützt. Der ganze Firlefanz entfällt bei Einsatz einer Datenbank. Wenn einige auch Logdatei mit Textdatei gleichsetzen, es geht damit nur so : Öffnen (Append), schreiben, schließen. Im Zeitraum zwischen öffnen und schließen kann KEIN anderer Benutzer etwas schreiben !!

[himitsu]

per Default ist MileMode nur auf fmOpenReadWrite gesetzt (in der Unit System)

also werden Dateien damit nicht exlusiv geöffnet.

Zitat von Infect:

jedoch bin ich davon ausgegangen, dass das bei Windows bei schreibenden Zugriffen automatisch so gesteuert wird.

indows macht nichts automaisch (wär ja auch noch schöner, weil sonst wüßte man ja nicht was windows wann machen würde), das muß man schon selber angeben.

Zitat von Infect:

Und Append ist für meine Begriffe ja ein schreibender Zugriff.

jupp, isser

Zitat von Infect:

Diese Annahme wurde für mich dadurch bekräftigt, dass ein schreibendes Öffnen ein und derselben Datei mittels Append eben NICHT durch mehrere Programme gleichzeitig möglich ist, sondern in einer Exception endet. Auch ohne diese besagte Zeile!!!

mein Tipp, wenn du uns nicht glaubst:
versuch doch einfach mal eine Datei mehrmals zu öffnen.

Zitat von Infect:

Das einzige, was ich daher von euch wissen wollte, ist, was das vorige setzten des FileMode genau bewirkt.

das wurde doch schon mehrmals gesagt.

Zitat von Infect:

Für mich ergeben sich zumindest bei mir KEINE sichtbaren Änderungen, wenn ich diese Zeile einfüge!!!

nicht?

Zitat von Infect:

Also frage ich nochmal: was bewirkt die ZeileFileMode := fmOpenReadWrite or fmShareExclusive; genau? Was ist anders, wenn ich die Zeile einfach weglasse? Mein Programm verhält sich wie gesagt genauso...

siehe oben (da per Default nicht gesetzt)


aber de Witz Dabei, ich hab es eben selbst mal ausprobiert und war "geschockt"
im Delphi 7 hier wird die Datei bei Schreibzugriff (Rewrite oder Append) immer im exklusiven Modus geöffnet, selbst wenn der nicht angegeben ist.

Und besonsters geschockt war ich, als ich selber angegeben hab, daß mit Sharing-Rechten (nicht Exklusiv) geöffnet werden sollte

Ich würde das jetzt mal ganz einfach als Delphifehler auslegen
und dazu raten dieses lieber nicht auszunutzen/vorauszusetzten (wer weiß ob/wann das mal repariert wird/wurde)


eigentlich müßte das Erste ohne Exception durchlaufen und das Zweite wie gewollt bei Append(F2); eine Exception auslösen.

Delphi-Quellcode:

Var F, F2: TextFile;

Begin
  // testdatei erstellen
  AssignFile(F, 'test.txt');
  Rewrite(F);
  CloseFile(F);

  //FileMode := fmOpenReadWrite or fmShareDenyNone;

  // mit sharing-rechten
  AssignFile(F, 'test.txt');
  Append(F);

  AssignFile(F2, 'test.txt');
  Append(F2);
  CloseFile(F2);

  CloseFile(F);



  FileMode := fmOpenReadWrite or fmShareExclusive;

  // exklusiv
  AssignFile(F, 'test.txt');
  Append(F);

  AssignFile(F2, 'test.txt');
  Append(F2);
  CloseFile(F2);

  CloseFile(F);
End;

[MatthiasR]

Zitat von himitsu:

...aber de Witz Dabei, ich hab es eben selbst mal ausprobiert und war "geschockt"
im Delphi 7 hier wird die Datei bei Schreibzugriff (Rewrite oder Append) immer im exklusiven Modus geöffnet, selbst wenn der nicht angegeben ist.

Und besonsters geschockt war ich, als ich selber angegeben hab, daß mit Sharing-Rechten (nicht Exklusiv) geöffnet werden sollte

Ich würde das jetzt mal ganz einfach als Delphifehler auslegen
und dazu raten dieses lieber nicht auszunutzen/vorauszusetzten (wer weiß ob/wann das mal repariert wird/wurde)...

AHA, da liegt also der Hund begraben! Ich hoffe jetzt versteht jeder von euch (v.a. du Reinhard!!!) warum mir nicht einleuchten wollte, warum ich unbedingt den FileMode umstellen muss, wenn es ohne genauso funktioniert (weil der FileMode wie ihr seht scheinbar standardmäßig auf Exclusive umgestellt wird). Da wurde mein Programm wohl etwas vorschnell als "reiner Unsinn" abgestempelt, wenn man es wie mir scheint zuvor nicht einmal selbst ausprobiert hat! Eigentlich wäre da ne Entschuldigung fällig...

Wie dem auch sei: danke himitsu, dass du der Sache auch mal auf den grund gegangen bist! So stellt sich das alles für mich in einem ganz neuen Licht dar! Wenn man wirklich davon ausgeht, dass es sich bei diesem Verhalten um einen Delphi-Fehler handelt, dann ergibt das explizite Umstellen (und Rückstellen!!!) des FileMode durchaus einen Sinn, das sehe ich absolut genau so! Seht ihr, man kann mich durchaus überzeugen (so viel zum Thema "Jungprogrammierer" und "Erkenntnisse der IT"...).

[himitsu]

Zitat von Infect:

dann ergibt das explizite Umstellen (und Rückstellen!!!) des FileMode durchaus einen Sinn

also das vorherige Speichern und nachfolgende Zückstellen MUß nicht unbedingt gemacht werden
FileMode ist leider eine Progamminterne Variable und wird in allen nachfolgenden Reset/Rewrite/Append-Aufrufen werwendet.
Wenn also irgendwo anders im Programm wieder eine Datei geöffnet wird, dann wäre es besser wenn man da den alten Wert wiederherstellt, da es da sonst zu problemen kömmen kann (wenn dort ein anderer oder der Standardwert benötigt wird)

nja, das Schlimme daran ist eigentlich daß man aufgrund dieses Fehlers keine Dateien mehrfach öffnen kann, selbst wenn man wöllte
(na ja, zum Glück hab ich mich da komplett auf die WinAPI umgestellt und dort läuft alles wie gewünscht ^^)