Verständnisfrage Seek

[Demian]

Moin,moin,

bin jetzt erst über die Funktion und Statement Seek bei sequentiellen Dateien gesolpert. 

Damit hat sich dieser Beitrag eigentlich auch erledigt, da nicht jedesmal die Datei komplett eingelesen werden muss und dadurch auch die Abfrage ob die Zeile bereits vorhanden ist überflüssig ist. Das verringert die Laufzeit natürlich ungemein, da ich das ganze dann doch in einer ansichtsaktion unterbringen werde. 

Ich speicher mir die letzte Dateiposition dann in einem Dok oder einer Datei auf dem Server weg. Allerdings ist mir bei der Dateiposition etwas unklar. Ich habe folgenden Code:

Code

Sub Click(Source As Button)
	Dim s As New NotesSession
	Dim db As NotesDatabase
	Dim doc As NotesDocument
	Dim Datei As Variant,  Dateistream As Integer
	Dim text As String
	
	
	Set db = s.CurrentDatabase
	
	'Frei Ddateinnummer suchen
	DateiStream = Freefile()
	
	'Dateinamen anhand aktuellen Monats ermitteln
	Datei = "G:\test.dat"
	
	'Datei öffnen und zeilenweise einlesen
	Open Datei For Input As DateiStream
	'Seek Dateistream,14
	Do While Not Eof(DateiStream)	
	                Line Input # DateiStream, text
		
		Set doc = db.createdocument
		doc.form = "Test"
		
		doc.test = text
		Call doc.Save(True,False)
		Print text
	Loop
	
	Msgbox Seek (Dateistream)
	
	Close DateiStream	
End Sub

Die Datei G:\Test.dat enthält folgenden Text:
1
2
3
4
5

bei Msgbox Seek (Dateistream) wird mir 14 ausgeworfen. Wieso 14? Hängt das mit den Absätzen zusammen?

Wenn ich jetzt obigen Code anpasse:

Code

Sub Click(Source As Button)
	Dim s As New NotesSession
	Dim db As NotesDatabase
	Dim doc As NotesDocument
	Dim Datei As Variant,  Dateistream As Integer
	Dim text As String
	
	
	Set db = s.CurrentDatabase
	
	'Frei Ddateinnummer suchen
	DateiStream = Freefile()
	
	'Dateinamen anhand aktuellen Monats ermitteln
	Datei = "G:\test.dat"
	
	'Datei öffnen und zeilenweise einlesen
	Open Datei For Input As DateiStream

                'Letzte ausgelesene Position
	Seek Dateistream,14

	Do While Not Eof(DateiStream)	
	                Line Input # DateiStream, text
		
		Set doc = db.createdocument
		doc.form = "Test"
		
		doc.test = text
		Call doc.Save(True,False)
		Print text
	Loop
	
	Close DateiStream	
End Sub

und die Datei um
6
7
8

erweitere wird mir ein "leeres" Dok erstellt. Auch wenn ich statt seek DateiStream,15 statt 14 einsetze, das selbe Ergebnis. Erst ab 16 wird kein leeres Dok erstellt. Warum? Ist es immer die letzte ausgeworfene Dateiposition + 2 oder kann das von Datei zu Datei variabel sein?

Gruß
Demian

[koehlerbv]

Seek wird in Zusammenhang mit binären Dateien oder recordweise gespeicherten Dateien verwendet, Du hast jedoch eine Textdatei (die Du aber natürlich als Binärdatei behandeln könntest).

Dass Messagebox Seek (Dateistream) 14 ausgibt, ist laut Deinem Code klar - Du hast den Dateizeiger ja ausdrücklich auf Position 14 gesetzt und fragst dann diese Position ab.

Bernhard

[Demian]

Moin Bernhard,

war ein c+p-Fehler das seek Dateistream,14 im oberen Code gehört da nicht hin. Habe es auskommentiert. Deswegen verstehe ich nicht, wie er auf 14 kommt es sind doch nur 5 Zeichen?


Hat es denn irgendwelche Auswirkungen, wenn ich seek im Zusammenhang mit Textdateien verwende?

Gruß
Demian

[flaite]

Hi,

was willst du eigentlich. Werte an die Text-Datei anhängen?
Das ist nämlich ganz einfach:

Open fileName [For {Input | Output | Append} ] As fileNumber [Len = bufferSize] [Charset = MIMECharsetName]
Where Input means read-only access to the file, Output means write-only access, and Append means write-only access starting at the end of the file. Access in all three sequential modes is one line at a time. To get an unused fileNumber, use the FreeFile function.

Mit Append hängst du die folgenden Einträge einfach an das File an.

du vergisst die carriage return und line break Zeichen in deiner Datei.
Auf deinem Editor steht nur

Code

1
2
3
4
5

Aber wenn du die Datei in Windows erstellt hast steht dort:

Code

1 <carriage return><line break>
2 <carriage return><line break>
3 <carriage return><line break>
4 <carriage return><line break>
5 <carriage return><line break>

carriage return und line break sind jeweils ein eigenes Zeichen. (char(13) und char(10)).

seek kannst du eigentlich als Anwendungsprogrammierer vergessen.
Das misst glaub ich die Bytes. Und die Byte Anzahl hängt wiederum vom verwendeten Encoding-Schema der Text Datei ab.
ASCII benutzt 7 bits für ein Zeichen.
Die ISO/IEC 8859 Familie benutzte 8 bits für ein Zeichen (http://en.wikipedia.org/wiki/ISO/IEC_8859)

Paßt alles noch in 1 byte. Wobei ISO 8859 eine Krücke ist. Davon gibts nämlich 15 Typen oder so. ISO-8859-1 reicht für Westeuropa noch aus. Es fehlen aber Sonderzeichen, die bei unseren slawischen Nachbarn gebräuchlich sind. 

Das ganze erhält noch eine weitere Dimension. Um das Jahr 1470 gelang es portugiesischen Seefahrern das Kap Bojador an der afrikanischen Westküste zu umsegeln. Das war der Durchbruch für den Beginn der europäischen Seeherrschaft. Ergebnis und vermutlich mehr noch Katalysator der europäischen Dominanz. Diese historische Epoche endet aber nun mit dem Aufstieg von Ländern wie China, die kein lateinisches Alphabet verwenden.
(http://mitworld.mit.edu/video/266/)
 
In einer zunehmend globalisierenden Welt reicht 1-byte-ist-8-bits nicht mehr aus.
In neuen Systemen wird in aller Regel UTF-8 favorisiert. Dort wird ein Zeichen durch 8 bis 32 bits repräsentiert (1 bis 4 bytes).
Damit werden die Zeichen des lateinischen Alphabets immer noch mit 1 byte dargestellt. Diakritische Sonderzeichen (ä, Ç, ¿, Ł etc.) aber schon mit 2 byte (anders als in der ISO-8859 Familie). Somit können alle diakritische Sonderzeichen (auch die von slawischen Sprachen) dargestellt werden. Ausserdem haben damit chinesische und andere nicht-lateinische Sprachen ihre eigenen byte-Kombinationen (bis zu 4).

Gruß Axel

[koehlerbv]

Ich empfehle dringendst das Studium des Kapitels "File handling" der DesignerHelp. Dort kann man nachlesen,
- warum Seek mit Textdateien gar nichts am Hut hat
- warum eine nicht-initialisierte Variable wie "Dateistream" als FileNum übel in die  Hose gehen kann
- wie man trotzdem text files in bestimmten Fällen als binary files auslesen kann (Axels Hinweise sind aber goldrichtig!)

Wie gesagt: Das sind Grundlagen, und diese stehen in der Dokumentation.

Bernhard

[flaite]

Wenn du sicher sein könntest, dass in einer Textdatei ein encoding verwendet wird, in dem
immer gilt
1 Zeichen == n Bytes ist,
könnte man damit was anfangen.
Die Gleichung gilt aber nicht mehr unbedingt.

Ich behaupte, dass heute grundsätzlich solche Zeichenpointer praktisch überhaupt nicht mehr verwendet werden. Zumindest nicht in den mir bekannten libraries. Das gilt auch für libraries, die binary Dateien bearbeiten.
Zum Bleistift Java Libraries zum bearbeiten von Excel Dateien wie Jexel.
Wenn ich da eine Excel Datei einlese, das Programm die Daten bearbeiten und später wieder rausschreiben lasse, wird die gesamte Excel Datei NEU erstellt (und die alte Datei so überschrieben).
Der Grund liegt einfach daran, dass es verdammt komplex wird, einen Datei Pointer zu verwalten und den an die richtigen Stellen das neue Zeug reinschreiben zu lassen. Es ist in solchen Fällen viel einfacher, die gesamte Datei neu zu erstellen. Und wenn du einfach was anhängen willst, nimm APPEND (s.o.).
Für komplexere read/write/editier/delete Operationen nimmt man dann eine Datenbank (relational oder hierarchisch wie Lotus Notes). Random Access Operationen auf Dateien spielten wohl in den 70ern eine große Rolle. Das ist lange her.

[flaite]

Wenn du das ganze nicht glaubst, bzw. es für verwirrt, unstrukturiert und seltsam hälst:
Lad dir doch einfach einen Hexeditor herunter. Z.B. hier: http://mh-nexus.de/hxd/

Eine mit Windows-Notepad erzeugte Datei:

Code

1
2
3
4
5

zeigt der Hexeditor so an:

Code

31 0D 0A 32 0D 0A 33 0D 0A 34 0D 0A 35 0D 0A

Ein Hexeditor zeigt einzelne Bytes nach den Hexadezimalen Zahlensystem an.
In ein dezimales Zahlensystem übersetzt steht da:

Code

31 13 10 32 13 10 33 13 10 34 13 10 35 13 10

Die Zeichenfolge 13 10 steht per Windows Konvention wie gesagt für neue Zeile.
Gemäss Windows 1250 encoding steht 31 für 1, 32 für 2, 33 für 3, 34 für 4, 35 für 5.
(http://en.wikipedia.org/wiki/Windows-1250)

Verständnis für die Art und Weise wie Computer mit "Textdateien" umgehen kann wichtig sein für Internationalisierung und überall dort wo "Textdateien" zwischen Computern ausgetauscht werden.
Oft stösst man da z.B. bei Web Services drauf. XML Dateien sind Textdateien. Und bei Web Services werden xml Dateien ausgetauscht. Die austauschenden Seiten müssen sich über das Encoding der Datei einig sein, sonst verstehen sie sich nicht.

Überigens funktioniert das seek schon. Nur ist es wie gesagt keine gute Idee. Die Unterscheidung zwischen "Binärdateien" und "Textdateien" ist nämlich eine Abstraktion, die sich auflöst wenn man nur tief genug gräbt. Es ist eine pragmatische Übereinkunft. Im physikalischen Speicher selbst sind alle Dateien Ketten von 0en und 1en. Ein Hex-Editor fasst diese Bits zu Bytes zusammen und transkribiert Bits als gleichlange Aglomerate von Bits (ein-Byte-sind-8-Bits) von dem binären Zahlensystem in das hexadezimal.

[Demian]

Moin,moin,

also ich habe .dat Dateien, die immer folgendermaßen aufgebaut sind:

Code

01002774640000063022F6070326070003
0100277464000005EE9185070326070102
0100277464000005EE9185070326153200
01002774640000063022F6070327051733
0100277464000005EE9185070329153212
01002774640000063022F6070330051942
01002664570000070CEFD7070326060208
0100266457000005EED94D070327164049
01002664570000070CEFD7070327164057

Es handelt sich hierbei um Buchungen aus unserer Zeiterfassung. Jede Zeile ist eine Buchung bestehend aus Lesestift, Buttonnummer, Datum und Uhrzeit. Diese Buchungen sollen in die Datenbank eingelesen werden, damit dort die Zuweisung der Mitarbeiter/innen anhand der Lesestifte erfolgt.

Hintergund ist, dass oft auf Buttons gestochen wird, die in der Zeiterfassung noch nicht angelegt sind. Dann beginnt die mühevolle Suche in diesen Dateien (für jeden Monat eine eigene .dat).

Es ist es so, dass mehrere 10000 Zeilen in diesen Dateien enthalten sein können. Bisher bin ich so verfahren ,dass ich alle bisher eingelesenen einer Datei Buchungen gelöscht und die Dateien komplett neu eingelesen habe. Das dauert natürlich seine Zeit. Wenn ich die Datei heute auslese, können morgen schon wieder 1000 neue Buchungen drin sein. Ich will mit seek ermitteln, wo ich zuletzt aufgehört habe und da entsprechend anzufangen auszulesen. Klappt auch ganz gut.

Aus der Hilfe:
For a binary or sequential file, Seek returns the current byte position within the file.

Ist doch genau das, was ich will, oder? Die einzelnen Zeilen enthalten 34 Zeichen, auswerfen tut er mir bei seek 36 pro Zeile. Also werden die Zahlen an sich mit jeweils 1 byte, und die Enter mit 2 byte gerechnet.

Glauben tue ich das schon, deswegen wollte ich ja zu Beginn wissen ob die "+2" mit den Entern (Returns) zusammenhängen. Und wie gesagt, es handelt sich um Dateien aus unserer Zeiterfassung, die immer nach obigen  Chema aufgebaut sind. Da brauche ich mir um länderbezogene Codierungen noch keine Gedanken zu machen.

Gibt es denn etwas anderes für das was ich machen will, außer seek?Bin für alles offen  Wie gesagt, bin erst gestern durch Zufall darauf gestoßen.

warum eine nicht-initialisierte Variable wie "Dateistream" als FileNum übel in die  Hose gehen kann

Wird sie durch = freefile() nicht initialisiert?

Trotzdem mal bisheriger Hintergrund-Agent im Anhang.


Gruß
Demian

[flaite]

Da die Dateien so symmetrisch aufgebaut sind, geht das natürlich.
Probleme ergeben sich nur, wenn sich in der nächsten Version der Zeiterfassung vielleicht das Format ändert. Um dich dagegen abzusichern könntest du dir auch die Nummer der zuletzt gelesenen Zeile merken und die Zeilen bis zu dieser Nummer zwar lesen, aber nicht verarbeiten.
Ich würds so machen, auch wenn das vielleicht pro Durchlauf ein bischen extra-Zeit kostet.

Reading from sequential files
To read data from a sequential file, open the file in input mode. Then use the Line Input # statement, the Input # statement, or the Input function, to read data from the file into variables.
Line Input # reads one line of text from a file, up to an end-of-line. The end-of-line is not returned in the string.
This example shows reading a file one line at a time until end-of-file. The Print statement displays the line and appends an end-of-line sequence.
Do Until EOF(idFile)
   Line Input #idFile, iLine
   Print iLine
Loop

[koehlerbv]

Wird sie durch = freefile() nicht initialisiert?

Doch. Ich habe diese Zeile schlicht überlesen - und bitte um Entschuldigung.

Bernhard

[Demian]

Moin,moin,

Um dich dagegen abzusichern könntest du dir auch die Nummer der zuletzt gelesenen Zeile

Also innerhalb der do while-Schleife nen Zähler setzen, der jedesmal um 1 erhöht wird und diesen dann speichern? Glaube ehrlich gesagt nicht, dass sich an den Quelldateien so schnell was ändert. Sind jetzt schon seit Jahren so.

Doch. Ich habe diese Zeile schlicht überlesen - und bitte um Entschuldigung.

Dann bin ich ja beruhigt 

Gruß
Demian

[flaite]

Ich würd das auf jeden Fall an einer gut sichtbaren Stelle sorgsam dokumentieren.

[Demian]

das werde ich im Agenten selbst noch tun, wenn alles läuft. Stehe jetzt noch vor dem Problem des Monatswechsel. Muss mal sehen, was ich da mache.

Vielen dank euch beiden.

Gruß
Demian

[flaite]

Eigentlich würde ich die Daten sogar ausführlich validieren.
Für mich sind alle Daten, die von aussen kommen erstmal dreckig und verdächtig.
Du könntest z.B. prüfen, ob die char(13), char(10) immer an der erwarteten Stelle stehen und sonst eine Warnung ausgeben. Es ist ein bischen gefährlich den Code auf dem Format einer zugekauften Anwendung zu basieren und es ist ziemlich einfach zu überprüfen, dass an den erwarteten Stellen immer der Line Break kommt.

[Demian]

Moin,moin,

Du könntest z.B. prüfen, ob die char(13), char(10) immer an der erwarteten Stelle stehen und sonst eine Warnung ausgeben

Naja, wenn das der Fall ist habe ich wahrscheinlich andere Probleme, die Daten werden dann nicht in der Zeiterfassung verbucht. Wenn ich dann in der Abrechnung bin und Fehlzeiten an die ME's schicke weil es schlicht so aussieht, als hätte der Mitarbeiter nicht gestochen, oder vielleicht in dieser Woche Urlaub usw. wirds erst spannend.


Gruß
Demian