Log Datei in VB einfügen

Hmm, dann würde ich das Ding aber nicht per direkten Schreibzugriff für den Client coden, sondern das Monitoring-Tool gleichzeitig als ActiveX-Server-EXE coden.

Dann kann er per Event-Trigger die Daten an den Client schicken ohne Gefahr zu laufen, dass ihm der Schreibprozess die Datei zu macht.

Klingt cool, aber ich glaube, das ist für einen (so wie ich es verstanden habe) noch nicht so erfahrenen Programmierer wohl etwas hoch.

Und je nach dem, wei die TXT-Datei nun gefüllt wird, muss doch einfach über eine Fehlerbehandlungsroutine abgefangen werden, dass die Datei gesperrt ist. Dies gehört für das Handling von Dateien, die NICHT in einer Datenbank liegen, jedoch gemeinsam genutzt werden, ohnehin grundsätzlich dazu. Dazu entwickelt man sich einmal eine eigene kleine Bibliotheksfunktion, die man dann immer wieder benutzen kann.
 
Klingt cool, aber ich glaube, das ist für einen (so wie ich es verstanden habe) noch nicht so erfahrenen Programmierer wohl etwas hoch.

Und je nach dem, wei die TXT-Datei nun gefüllt wird, muss doch einfach über eine Fehlerbehandlungsroutine abgefangen werden, dass die Datei gesperrt ist. Dies gehört für das Handling von Dateien, die NICHT in einer Datenbank liegen, jedoch gemeinsam genutzt werden, ohnehin grundsätzlich dazu. Dazu entwickelt man sich einmal eine eigene kleine Bibliotheksfunktion, die man dann immer wieder benutzen kann.

Hmmm, ist auch wieder wahr. Hatte übersehen, dass er geschrieben hat, dass er Anfänger ist. Da sind dann Client-Server-Anwendungen wirklich ne Nummer zu hoch.

Also vom Prinzip schlägst du vor wie folgt:
Im Monitoring-Tool die Datei im Schreibmodus mit Lock öffnen, Daten reinschreiben, Datei schliessen, Lock auflösen. Das ganze läuft wiederholend innerhalb eines Zeit-Intervalls ab.

Im Client auch in einem Zeitintervall, immer wieder testen, besagte Datei versuchen zu öffnen, und zwar solange, bis der Lock aufgelöst ist, und dann die Daten auslesen, und die Datei sofort wieder schliessen.

Wird er aber ein Problem mit der Snychronisation bekommen. Ich bin mir ziemlich sicher, dass es zu einer Zugriffskollission kommen wird.

Ein Derivat von Bobis Idee, wäre: Die TXT vom Server auf Lokal zu kopieren, und dort ohne Einschränkungen zu öffnen. Nachteil: Je nach Grösse der Datei hat er eine Zeitverzögerung. Es ist dann definitiv nicht in "Echtzeit", was in meinen Augen jedoch ein Hauptfeature in so ner Alarm-Monitoring sein sollte.
 
Zunächst einmal verstehe ich die Grundfrage von Blackice05 (der sich aber anscheinend in Luft aufgelöst hat) so, dass die Datei auf dem Server liegt, denn er soll ja ein Monitoring-Tool schreiben (Monitor=Gucken, was los ist), und kein Tool, was eine Alarmanlage ausliest (was ja auch wesentlich mehr Grundkenntnisse benötigen würde!).

Daher muss er die Datei theoretisch nur zum Lesen öffnen, es sei denn, er löscht sie jedesmal nach dem Lesen (Vorteile dafür habe ich oben geschildert).

Der Zugriff und die tatsächliche Sperrzeit einer kurzen Datei, die ja offensichtlich nur die Statusmeldungen der 5-6 Bereiche beinhaltet, ist verschwindend kurz. Ich betreue eine Menge Anwendungen, die teilweise aus DOS-Anwendungen (Visual Basic für DOS 1.0) als auch Windows-Anwendungen (VB6) bestehen, und wo genau mit solchen Dateien gearbeitet wird. Vor 20 Jahren, als manche der DOS-Anwendungen ursprünglich entstanden sind, war dies gängige Praxis, an SQL-Server o.ä. war damals nicht zu denken. Teilweise greifen da bis zu 100 User drauf zu.

Dies läuft völlig problemlos, wobei natürlich eine kleine Routine sicherstellen muss, dass bei eventuellen Sperren das Programm angemessen reagiert. Das ist für den Anwender in der Regel nicht spürbar, letztendlich machen auch Datenbankserver nichts anderes (nur dass man sich darum selbst weniger kümmern muss).

Daher sind sogenannte Kollisionen hier kein Thema. Und wirkliche Echtzeit ist in diesem Fall, wenn man den Post richtig liest, nun auch nicht gefordert, er will ja nur alle 10 Sekunden nachsehen, wie der Status ist.
 
Achso. Ich dachte er muss 2 Programme coden: 1x Alarmanlage auslesen, 1xAuswertung.

Wenn die txt sozusagen von irgendeinem Programm auf den Server gestellt wird, denke ich aber, dass mein Ansatz der bessere ist:
Wenn er die Datei alle 10 Sekunden vom Server herkopiert per SHFileOperation, ist es egal, ob das Main-Programm gerade in die Datei schreibt, da Windows dann die letzte gespeicherte Version nach Lokal kopiert und diese dort ablegt, und er bekommt keine Kollission (habs gerade mit ner offenen Text-Datei bei mir getestet.). Mit der lokalen Version kann er dann tun und lassen was er will
 
Zurück