Mit XE2 auf dBase-Datenbank lesend zugreifen

[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 von musicman56:

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

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