Mit XE2 auf dBase-Datenbank lesend zugreifen

[p80286]

Zitat von dummzeuch:

Mir steht das naemlich demnaechst auch bevor und ich bin "wild entschlossen" das durchzuziehen. Allerdings geht es bei uns um lesen *und* schreiben. Erstmal 32 Bit, aber irgendwann auch 64 Bit.

Wäre das nicht die Gelegenheit auf eine "modernere" DB umzusteigen?

Gruß
K-H

[dummzeuch]

Zitat von p80286:

Zitat von dummzeuch:

Mir steht das naemlich demnaechst auch bevor und ich bin "wild entschlossen" das durchzuziehen. Allerdings geht es bei uns um lesen *und* schreiben. Erstmal 32 Bit, aber irgendwann auch 64 Bit.

Wäre das nicht die Gelegenheit auf eine "modernere" DB umzusteigen?

Ist zwar schon etwas aelter, aber ich dachte, ich antworte trotzdem mal: Die BDE ist veraltet und wird nicht mehr gepflegt. Das Tabellen- und Index-Format DBase ist zwar alt, aber nicht veraltet. Insbesondere kann es jedes wichtige Programm lesen, z.B. MS Office und Open Office.

Es hat seine Macken, z.B. gehen grosse Tabellen schnell mal kaputt, wenn man Operationen abbricht, aber die Vorteile ueberwiegen.

Die Alternative, die von unseren Kunden gerne mal gefordert wird, waere XML. Und das ist definitiv kein Format, welches ich zum Speichern und Lesen von (Zwischen-)Ergebnissen verwenden will. (Der Kunde, der es will, bekommt natuerlich sein XML, aber deshalb muss ich es ja nicht selbst verwenden.)

[Furtbichler]

Klar, DBF-Dateien kann man mit jedem Programm lesen. Deshalb ist es auch eine gute Wahl, um Daten zu exportieren. Wieso muss man dann aber dieses fehleranfällige Format zum Speichern der Daten benutzen? Du schreibst ja selbst, das die Gefahr besteht, Daten zu verlieren.

Ich würde z.B. SQLite ins Auge fassen, um die Daten lokal zu speichern. Auch Firebird Embedded ist eine gute Wahl.

Bei wenigen Daten (also so 1000 oder 5000) und wenigen Tabellen (<10) reicht auch ein TClientDataset und das native XML-Format. Aber SQL hat man dann nicht.

Eine andere Möglichkeit wäre ein TDataset mit in-Memory SQL-Fähigkeiten, wie z.B. das alte TjanSQL (wobei ich nicht weiss, ob das noch kompatibel ist).

Mein persönlicher Favorit wäre allerdings SQLite oder FB Embedded, wobei ich SQLite den Vorzug geben würde (bei kleineren DB), weil der Footprint kleiner ist.

Natürlich gibt es bestimmt auch andere Desktop-Formate (Access mag ich immer noch).

[dummzeuch]

Zitat von Furtbichler:

Klar, DBF-Dateien kann man mit jedem Programm lesen. Deshalb ist es auch eine gute Wahl, um Daten zu exportieren. Wieso muss man dann aber dieses fehleranfällige Format zum Speichern der Daten benutzen? Du schreibst ja selbst, das die Gefahr besteht, Daten zu verlieren.

Kompatibilitaet ist ein weiterer Grund.

Fuer unsere spezielle Anwendung ist das sogar extrem: Wir haben noch ein paar DOS/Borland Pascal-Programme im Einsatz, die ebenfalls auf die Daten zugreifen muessen (Daher kommt das Format urspruenglich.) Sobald alle Programme nach Windows/Delphi portiert sind, besteht die Moeglichkeit, das Format zu wechseln. Allerdings ist schwer zu entscheiden, wann das der Fall ist, denn ich entdecken mindestens einmal im Monat wieder ein DOS-Programm, welches fuer eine spezielle Anwendung unverzichtbar ist, von dem ich aber vorher nicht wusste, dass es existiert. Das kommt dann auf meine Abschussliste und wird dann, wenn Zeit ist, portiert oder die Funktion in ein anderes Programm integriert.

twm