DBF Standardausgabenreihenfolge der ROWS
-
http://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT
(über Wikipedia, kannst Du eigentlich auch ...)
Im Prinzip ein Header mit den Feldnamen, -längen und -typen. Daraus ergibt sich
die feste Satzlänge der darauf folgenden Daten.
-
Es ist einfach und/aber ich habe keine Aussage darüber gefunden ob die Ausgabe immer in der Reihenfolge passiert wie sie in der Datei steht.
Es liegt ja im Grunde nicht an der DBF-Datei sondern an der Bibliothek. Diese ist fürs lesen und ausgeben zuständig.
Dachte das es in der Spezifikation von DBASE definiert ist.
Brauche nur eine Bestätigung von jemandem der sich damit beschäftigt hat.
Ich weiß das es bei RDBMS nicht definiert ist.
Leider gibt es solche DB-Formate immer noch.
Naja VFP läuft ja bald aus.
-
Zumindest dBASE gibt das in der Reihenfolge aus wie's reingelaufen ist.
-
Scheppertreiber schrieb:
Zumindest dBASE gibt das in der Reihenfolge aus wie's reingelaufen ist.
Nicht notwendigerweise, würde ich vermuten. Schließlich kann man in dBase auch Datensätze löschen (ich meine richtig löschen und nicht nur als gelöscht markieren). Wird dieser Speicherplatz nicht mehr verwendet? Wenn doch, wie wirkt sich das auf die Reihenfolge der Ausgabe aus? Wird auch dann noch in der Eifügereihenfolge ausgegeben? Was ist, wenn ein Primärindex definiert ist? Sollte dann nicht die Ausgabe in dessen Reihenfolge erfolgen?
-
dBASE selbst setzt ein Löschkennzeichen am Beginn jedes Records.
Mit (mir fällt der Befehl nicht mehr ein, zu lange her) wird die DBF gepackt,
die mit dem Löschkennzeichen (glaube, es war ein '*') werden dabei in den
Rundordner gejagt.
-
Also so wie ich das gelesen habe wird freier Platz genutzt und dort neue Datensätze geschrieben.
Es ist also nicht definiert und nur ein AutoInc kann einem ROW eindeutig eine Platz in der Ausgabe zuweisen.
-
Unix-Tom schrieb:
Also so wie ich das gelesen habe wird freier Platz genutzt und dort neue Datensätze geschrieben.
Es ist also nicht definiert und nur ein AutoInc kann einem ROW eindeutig eine Platz in der Ausgabe zuweisen.dBASE (bis v 4) kennt keinen autoincrement. Gelöschte (=markierte) Records werden
definitiv nicht überschrieben. Wie das die Nachfolger machen ? kA.
-
Kann dBase nicht Indexe verwalten?
Spätestens dann ist schluss mit "einfachem Format" und auch schluss mit "Reihenfolge garantiert"...
-
Scheppertreiber schrieb:
Library ??? Wozu denn ? Das Format ist dermaßen einfach ...
Scheppertreiber schrieb:
http://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT
(über Wikipedia, kannst Du eigentlich auch ...)
Im Prinzip ein Header mit den Feldnamen, -längen und -typen. Daraus ergibt sich
die feste Satzlänge der darauf folgenden Daten.Das ist jetzt nicht dein Ernst?
Allein die Spec zu lesen dauert Länger als eine dBase Lib einzubinden.
An einer Implementierung die sowas dann wirklich korrekt lesen kann sitzt man mindestens ein paar Tage. Zumindest wenn man es halbwegs vollständig (->Codepage-Support etc.) und halbwegs fehlerfrei hinbekommen will.
-
hustbaer schrieb:
Kann dBase nicht Indexe verwalten?
Spätestens dann ist schluss mit "einfachem Format" und auch schluss mit "Reihenfolge garantiert"...Die Indexdateien sind extern, nicht in der Datenbank eingebunden (deshalb
auch früher mal öfter ein "reindex").Das ist jetzt nicht dein Ernst?
Die Lib bindet sich auch nicht von selbst ein. Unter Windows gibt es (glaube
ich) die Möglichkeit das per ODBC zu bearbeiten. Ganz ohne Lib.Wozu Codepage-Support ? Hast Du Daten aus Südkorea in der Landessprache ?
-
@Scheppertreiber:
Und ODBC ist keine Lib, oder wie
Ne, ehrlich, ne Lib einzubinden ist IMO einfacher.
CSV Files würde ich vielleicht noch selbst parsen, alles andere nur wenns garnicht anders geht.
-
Kommt drauf an ... wie immer.
Es gibt auch Kunden die nicht mal ein *.dbf unfallfrei hinbekommen *grrrr*
zB mit Excel bearbeiten und dann Speichern. *umkipp*