Domino 9 und frühere Versionen > ND7: Entwicklung

Verständnisfrage Seek

<< < (2/3) > >>

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

--- Ende Code ---

zeigt der Hexeditor so an:

--- Code: ---31 0D 0A 32 0D 0A 33 0D 0A 34 0D 0A 35 0D 0A

--- Ende Code ---
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

--- Ende Code ---
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
--- Ende Code ---

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.


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

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.


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

--- Ende Zitat ---

koehlerbv:

--- Zitat ---Wird sie durch = freefile() nicht initialisiert?
--- Ende Zitat ---

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

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete