Moin,moin,
bin jetzt erst über die Funktion und Statement Seek bei sequentiellen Dateien gesolpert. ::)
Damit hat sich dieser Beitrag (http://atnotes.de/index.php?topic=35739.0) 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:
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:
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
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
Aber wenn du die Datei in Windows erstellt hast steht dort:
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>
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
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:
zeigt der Hexeditor so an:
31 0D 0A 32 0D 0A 33 0D 0A 34 0D 0A 35 0D 0A
In ein dezimales Zahlensystem übersetzt steht da:
31 13 10 32 13 10 33 13 10 34 13 10 35 13 10
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.
Moin,moin,
also ich habe .dat Dateien, die immer folgendermaßen aufgebaut sind:
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 ;D 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