DBF Standardausgabenreihenfolge der ROWS



  • Hallo Leute,

    bei einem RDBMS kann nie vorhergesagt werden in welcher Reihenfolge das RDBMS die ROWS zurück gibt.
    Ich suche jetzt eine DOKU oder ähnliches ob dies auch beim Format DBF so ist oder ob die Ausgabe immer gem. Platz in der DBF-Datei ist.
    Ich spreche hier jetzt nicht von Sortierung ORDER BY.

    Danke



  • DFB-Datei ? Im Moment ist Sommerpause - StPauli rulez 😉

    Meinst Du dBASE ? Ohne Index läuft das in der Reihenfolge wie's drinnen steht
    raus ("physical Index").



  • Klar, 2 Mal richtig und einmal falsch. 😃

    Ich meine eigentlich VFP. Verwendet ja auch DBF.
    Ist es sichergestellt das es so ausgegeben wird wie es in der Datei steht oder ist es einfach nicht definiert. Wenn es nicht definiert ist dann ist es auch nicht sichergestellt.



  • Ich würde sagen wenn es in der Dokumentation der verwendeten Library nicht explizit steht, wird es wohl nicht garantiert sein. Bzw. wäre es mir zumindest zu unsicher als dass ich mich darauf verlassen würde.



  • Library ??? Wozu denn ? Das Format ist dermaßen einfach ...



  • Scheppertreiber schrieb:

    Library ??? Wozu denn ? Das Format ist dermaßen einfach ...

    Ach?
    Link?



  • 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*


Anmelden zum Antworten