Mit XE2 auf dBase-Datenbank lesend zugreifen

[musicman56]

Hallo,

bedingt durch den Umstieg auf XE2 kann ich TDbf nicht mehr verwenden, und suche daher einen Ersatz. Ob kommerziell oder Open Source (also Preis/Kosten) ist egal, nur der Overhead sollte so gering wie möglich sein. Die Lösungen die ich bisher im WEB gefunden habe, sind mir viel zu komplex. Ich möchte ja nur Daten auslesen, ohne Index, ohne Memo. Hab auch schon versucht, TDbf für XE2 anzupassen, aber da komme ich (schon ca. einen Tag investiert) nicht mehr weiter. Notfalls muss ich eben direkt an die Files ran, aber bis das zuverlässig läuft, dauert mir zu lange. Darum darf's auch ruhig was kosten. Nur schlank muss es sein.

Für einen Tipp wäre ich sehr dankbar.

[mkinzler]

Sollte über ADO gehen. U.U. mit Treiber für FoxPro
http://msdn.microsoft.com/en-us/vfoxpro/bb190232.aspx

[musicman56]

Hallo Markus,

danke für die schnelle Antwort. Vielleicht hab ich mich falsch ausgedrückt: "Nativ", also ohne zusätzliche Treiber, und das scheint mir via ADO nicht möglich zu sein, oder doch?

[mkinzler]

Doch sollte gehen. Die Frage ist nur des möglichen Funktionsumfangs.

[s.h.a.r.k]

Zitat:

Zitat von mkinzler (Beitrag 1179533)

Doch sollte gehen. Die Frage ist nur des möglichen Funktionsumfangs.

Zitat:

Zitat von musicman56 (Beitrag 1179524)

Ich möchte ja nur Daten auslesen, ohne Index, ohne Memo.

Deine Lösung sollte daher wohl einwandfrei funktionieren :)

[exilant]

Zitat:

Zitat von musicman56 (Beitrag 1179524)

Hallo,
Ich möchte ja nur Daten auslesen, ohne Index, ohne Memo.

dBase III-V .DBF Dateien zu lesen, ohne Memos und ohne Indexe ist eher trivial.
Das Dateiformat findest du hier.
Eine Routine die das lesen kann sollte in weniger als einem Vormittag zu schreiben sein.
Ansonsten könnte man die hier zu findenden sourcen anpassen.

[Furtbichler]

Alternative: TDBF

[musicman56]

@exilant

Hab's mir runter geladen. Das sieht doch schon mal gut aus. Vielen Dank!

Zitat:

Eine Routine die das lesen kann sollte in weniger als einem Vormittag zu schreiben sein.

Na ja, ich denke es wird schon einen Tag dauern. Aber arbeitsscheu bin ich ja nicht :wink:

@Furtbichler

Den Thread hab ich natürlich schon zuvor gelesen. Ärgere mich auch immer, wenn User in Foren Fragen stellen, die schon zig-mal beantwortet wurden. Aber, mit diesem Thread bin ich nicht weiter gekommen. Es gibt offensichtlich keine Version von TDBF die unter XE2 läuft.

[mkinzler]

Zitat:

Zitat von Furtbichler (Beitrag 1179553)

Alternative: TDBF

TDBF ist ein guter Ersatz für TDBF :o

Zitat:

bedingt durch den Umstieg auf XE2 kann ich TDbf nicht mehr verwenden, und suche daher einen Ersatz.

[musicman56]

Zitat:

TDBF ist ein guter Ersatz für TDBF

Da stimme ich dir vollkommen zu, aber woher nehmen ist doch die Frage? Wie schon gesagt, am Anpassen an XE2 hab ich mir schon die Zähne ausgebissen :oops:

[shmia]

Mit Delphi Bordmitteln geht das so:
Du nimmst eine ADOConnection und dann:

Delphi-Quellcode:

function BuildDBaseConnectionString(const directory:string):string;
begin

   (* evtl. auch so; es ist noch nicht klar ob das besser wäre

   // DSN unabhängige Connection
   Result := 'Driver={Microsoft dBASE Driver (*.dbf)};DriverID=277;' +
      'Dbq=' + path;
   *)

   Result := 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+directory+
     ';Extended Properties=dBase 5.0;Persist Security Info=False';
end;
...
ADOConnection1.ConnectionString := BuildDBaseConnectionString('C:\dbaseordner\');
ADOConnection1.Connected := True;

ADOQuery1.SQL.TEXT := 'SELECT * FROM Adressen';  // öffnet Adressen.dbf
ADOQuery1.Open;

Solange du keine Memofelder oder Indices verwendet, funktioniert das astrein.

[musicman56]

Hallo Andreas,

mit ADO hab ich noch nicht gearbeitet, nur mit der BDE und später dann (seit 2000) mit Nexus. Darum mag meine Frage dumm erscheinen. Funktioniert das dann auf jedem OS? Ich hab viele Kunden die nutzen noch XP.

[Bernhard Geyer]

Zitat:

Zitat von musicman56 (Beitrag 1179578)

Darum mag meine Frage dumm erscheinen. Funktioniert das dann auf jedem OS? Ich hab viele Kunden die nutzen noch XP.

Bisher wird auf allen Windows-Systemen (bis auf die Embedded-Verisonen) die nötige JET-Engine (DB-Engine von Access) standardmäßig mit ausgeliefert.
In Zukunft Win9 und neuer könnte das anders sein da MS schon Jahre darauf hin arbeitet Access durch eine kleine Version des MS SQL-Servers abzulösen.

[dummzeuch]

Zitat:

Zitat von musicman56 (Beitrag 1179563)

Zitat:

TDBF ist ein guter Ersatz für TDBF

Da stimme ich dir vollkommen zu, aber woher nehmen ist doch die Frage? Wie schon gesagt, am Anpassen an XE2 hab ich mir schon die Zähne ausgebissen :oops:

Was funktioniert denn nicht? Liegt's am Port nach 64 Bit oder an was anderem?

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.

(btw: Ich hoffe alle hier sind sich darueber im Klaren, dass tdbf unter der LGPL steht.)

[musicman56]

Hallo,

obwohl ich meine Brötchen damit verdiene, bin ich was das Programmieren anbelangt Autodidakt, d.h. an einigen Stellen fehlt mir einfach das tiefergehende Wissen. Das nur mal als Hintergrundinfo. Ich erwähne das auch, weil an anderer Stelle hier über Vor- und Nachteile von Open Source sowie das Verhalten von Programmierern die sich an Open-Source-Projekten beteiligen ziemlich kontrovers diskutiert wurde. Ich habe über's Web schon sehr viel Hilfe erfahren, und wenn ich die Möglichkeit habe der Community etwas zurück zu geben, dann bin ich gerne bereit dazu. Somit wäre für mich selbstverständlich gewesen, wenn ich es denn hinbekommen hätte, dass ich TDBF zur Verfügung gestellt hätte.

TDbf von TDataset abgeleitet erbt die als virtual deklarierte funktion AllocRecordBuffer. Die ist in TDbf natürlich überschrieben und nicht vom Typ TRecordBuffer (= PByte). Da komm ich nicht weiter, weil dahinter noch ein Rattenschwanz an Abhängigkeiten folgt. Für einen Spezialisten denke ich, wäre das in ein paar Stunden zu machen.

Zwischezeitlich hab ich mir "jbDbf.pas" runtergeladen und mit ein paar kleinen Änderungen ist es mir gelungen, das Ganze unter XE2 zum Laufen zu bringen. Es ist nur eine einzige Unit ohne viel SchnickSchnack, sehr übersichtlich, und darum auch sehr einfach zu verändern bzw. zu erweitern.

[p80286]

Zitat:

Zitat von dummzeuch (Beitrag 1179786)

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:

Zitat von p80286 (Beitrag 1179887)

Zitat:

Zitat von dummzeuch (Beitrag 1179786)

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:

Zitat von Furtbichler (Beitrag 1191795)

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