# Log Datei in VB einfügen



## BLACKICE05 (27. Oktober 2008)

Servus ich bin seit gerade eben Angemeldet bin Tim 18 Jahre alt und mache eine Ausbildung zum IT-System-Kaufmann ich habe jetzt eine "kleine" Programmierungs- Übungsaufgabe bekommen. 

So nun Stehe ich vor einem Problem die Grafische Oberfläche ist soweit fertig jetzt geht’s ans Realisieren. 

Nun zu meinem Problem: 

Ich soll eine Alarmanlagen Monitoring schreiben (Grafische Anzeige der Grundrisse die sind mit Grün und Rot deklariert (Grün = Unscharf und Rot = Scharf) ich habe auf unserem Server hier eine „Alarmlog.txt“ Datei 

So meine Frage ist 

Wie kann die diese .txt. Datei einfügen und sagen wir alle 10 sec. Aktualisiert falls sich was ändert (z.B. von Scharf auf Unscharf) das Bild dann einfach von Rot in Grün Wechselt. Ebenso haben wir 5 verschiedene Bereiche die alle extra Scharf/Entschärft werden können. 

Natürlich will ich keinen ganzen Code sondern nur wie ich die .txt. Datei mit Aktualisierung einfügen kann und das dass Programm auf die Datei zugreift. 

Ich hoffe ich habe das alles verständlich erklärt wenn mir jemand helfen kann wäre ich Ihm sehr dankbar. 

Ich wünsche euch einen schönen Tag noch 

MfG


----------



## bobi_ (27. Oktober 2008)

hey tim,

so in etwa?




```
'benötigte komponenten: microsoft internet transfer control 6.0
Dim seitezumauslesen As String 'deine seite als string deklerieren
Dim datenvonseite as string
seitezumauslesen = "http://www.tutorials.de/bla.log" ' <-- deine seite
If Not Inet1.StillExecuting Then 'wenn inet1 gerade nicht benutzt wird -> soll deine aufgabe ausgeführt werden
datenvonseite = Inet1.OpenURL(seitezumauslesen) 'die textdatei vom server wird in den string "datenvonseite" ausgelesen.
End If
```

 diesen code kannst du jetzt z.b. in einen timer kopieren, und dem timer einen passenten interval geben. (10 sekunden -> interval = 10000)


----------



## ronaldh (28. Oktober 2008)

Hallo Tim,

wie eine Textdatei eingelesen wird, hängt natürlich auch vom Aufbau der Datei ab (hat sie z.B. eine feste Satzlänge, sind dort Zeilen, in denen die Felder durch Komma/Tab oder was auch immer getrennt sind?). 

Das was bobi geschrieben hat, betrifft das Internet, nach Deinem Problemfall gehe ich jedoch stark davon aus, dass es sich hier um einen lokalen Netzwerkserver handelt. Dazu brauchst Du natürlich kein Internet-Control.

Generelles zum Lesen und Schreiben von Dateien findest Du u.a. hier.

ronaldh


----------



## Zvoni (28. Oktober 2008)

Einwurf von der Seite: Wie ist die Situation, wenn ich per VB-Code eine Datei zum lesen öffne (Modus sei mal egal)? Ist diese Datei dann für andere Prozesse gesperrt?

Sollte man berücksichtigen! Falls die Datei dann gesperrt ist, kann der andere Prozess (Monitoring-Prozess) nicht in die Datei schreiben, solange sie offen ist.


----------



## bobi_ (28. Oktober 2008)

ronaldh hat gesagt.:


> Hallo Tim,
> 
> 
> 
> ...







> ich habe auf unserem Server hier eine „Alarmlog.txt“ Datei


----------



## Zvoni (28. Oktober 2008)

> ich habe auf unserem Server *hier* eine „Alarmlog.txt“ Datei



Das wichtige Wort ist nicht Server, sondern das Wort "hier"!

Server heisst nicht automatisch Internet!


----------



## Blackhawk50000 (28. Oktober 2008)

gibts so ne coole seite auch für C#?


----------



## ronaldh (28. Oktober 2008)

Zvoni hat gesagt.:


> Einwurf von der Seite: Wie ist die Situation, wenn ich per VB-Code eine Datei zum lesen öffne (Modus sei mal egal)? Ist diese Datei dann für andere Prozesse gesperrt?
> 
> Sollte man berücksichtigen! Falls die Datei dann gesperrt ist, kann der andere Prozess (Monitoring-Prozess) nicht in die Datei schreiben, solange sie offen ist.



Grundsätzlich ist die Datei erstmal nicht gesperrt, wenn sie mit Open von VB aus geöffnet wird, dies muss dann explicit mit dem Lock-Befehl durchgeführt werden (dann natürlich nicht das Unlock vergessen. Lock und Unlock können auf File- und Recordebene erfolgen.

Allerdings sollte das VB-Leseprogramm damit rechnen, dass der Monitoring-Prozess die Datei beim Schreiben lockt, und darauf entsprechend reagieren. Es erfolgt dann ja ein Fehler, der abgefangen werden muss, und ein paar Sekunden später wieder ausgeführt werden muss.

Es wäre für Blackice05 natürlich auch zu prüfen, wie die Monitoring-Daten erzeugt werden. Es wäre sicherlich sinnvoll, die Datei nach dem Einlesen jedesmal zu löschen, was natürlich nur geht, wenn sie dann wieder neu erzeugt werden kann. Auf diese Weise würde man nämlich auch mitbekommen, wenn eines der Geräte nicht mehr antwortet (weil sabotiert oder defekt).

Grüsse
ronaldh


----------



## ronaldh (28. Oktober 2008)

Blackhawk50000 hat gesagt.:


> gibts so ne coole seite auch für C#?



Probiers mal hier!


----------



## Zvoni (28. Oktober 2008)

ronaldh hat gesagt.:


> Grundsätzlich ist die Datei erstmal nicht gesperrt, wenn sie mit Open von VB aus geöffnet wird, dies muss dann explicit mit dem Lock-Befehl durchgeführt werden (dann natürlich nicht das Unlock vergessen. Lock und Unlock können auf File- und Recordebene erfolgen.
> 
> Allerdings sollte das VB-Leseprogramm damit rechnen, dass der Monitoring-Prozess die Datei beim Schreiben lockt, und darauf entsprechend reagieren. Es erfolgt dann ja ein Fehler, der abgefangen werden muss, und ein paar Sekunden später wieder ausgeführt werden muss.
> 
> ...



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.


----------



## ronaldh (28. Oktober 2008)

Zvoni hat gesagt.:


> 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.


----------



## Zvoni (28. Oktober 2008)

ronaldh hat gesagt.:


> 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.


----------



## ronaldh (28. Oktober 2008)

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.


----------



## Zvoni (28. Oktober 2008)

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


----------

