Domino 9 und frühere Versionen > ND7: Entwicklung
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. ;D
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
--- Ende Code ---
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
--- Ende Code ---
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:
--- Zitat ---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.
--- Ende Zitat ---
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
--- Ende Code ---
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>
--- Ende Code ---
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
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln