DBF-Neulingfrage: Wie kann ich eine Query über mehrere DBF-Tabellen joinen?

[baurat]

Hallo zusammen,

ich arbeite seit langem mit MySQL und Zeos problemlos aus Delphi 6 prof (inzwischen etwas angegraut, tuts aber). Nun muss ich aus einer "Fremddatenbank" mit offenbar uralten *.dbf-Dateien einige Infos auslesen.

Dazu habe ich die tdbf-Komponente (http://tdbf.sourceforge.net/) gefunden, mit der ich schön auf die dbf-Tabellen komme.

In der "echten" SQL-Welt hole ich mir die gewünschten Informationen als Join über mehrere Tabellen (select * from tabelle1, tabelle2 where ....).

Nun meine Frage: wie geht das mit den DBF-Tabellen? Gibts überhaupt sowas wie eine Query? Wenn ja, wie müssen da die Pfadangaben zu den einzelnen Tabellen rein?

Konkret:
pfad\schueler.dbf mit schuelerid als Primärschlüssel
pfad\kurs.dbf mit kursid als Primärschlüssel
pfad\belegung.dbf mit belegungid als Primärschlüssel und Fremdschlüsseln fs_schuelerid und fs_kursid (welcher Schueler belegt welchen Kurs)

Jetzt hätt ich gern sowas wie

Code:

Select s.name, s.vorname, k.kursname from schueler s, kurs k, belegung b 
where s.schuelerid = b.fs_schuelerid and 
b.kursid = k.kursid and b.kursid = 23

(dh. Namen aller Schueler im Kurs 23)


Ich habe dazu leider keine schlüssigen Infos gefunden. Mir ist klar dass das ein Uralt-System ist, aber das hilft mir nichts, ich muss da an die Daten ran und wäre über einen einfachen und schnellen Weg dankbar...

Vielen Dank für die Hilfe (und falls es trivial ist bitte nicht steinigen...) :-)

Danke!

LG Heiko

[p80286]

DBF? war das nicht DBase?
Wenn ich mich nicht vertue kann die BDE doch mit DBase umgehen??
Ansonsten in ein "richtiges" System importieren und dann kannst Du mit SQL arbeiten.
(ACCESS hat noch importfilter für DBF-Dateien, von da aus sollte der Import in ein richtiges System wohl funktionieren)

Gruß
K-H

[baurat]

Hi K-H, Danke für deine schnelle Antwort.

Zitat:

Zitat von p80286 (Beitrag 1123720)

DBF? war das nicht DBase?
Wenn ich mich nicht vertue kann die BDE doch mit DBase umgehen??
Ansonsten in ein "richtiges" System importieren und dann kannst Du mit SQL arbeiten.
(ACCESS hat noch importfilter für DBF-Dateien, von da aus sollte der Import in ein richtiges System wohl funktionieren)

Ähmm... ob das jetzt dbase-Daten sind, weiß ich gar nicht... ich glaub aber irgendwie wurde das ursprünglich mit Foxpro oder so gemacht...? Keine Ahnung!
Ich hatte mit der BDE noch nie was am Hut, deswegen hilft mir der gut gemeinte Hinweis leider nicht. Das Lesen der dbf-Files ist aber wie gesagt kein Problem.

Zitat:

Ansonsten in ein "richtiges" System importieren und dann kannst Du mit SQL arbeiten.

Das hab ich mir auch schon überlegt, aber die dbf-Daten ändern sich laufend, so dass halt gern "direkt" daraus lesen würde und nicht über die Krücke dbf > Access > mysql o.ä. muss, denn den Importprozess müsste ich dann ja auch jedes Mal neu durchführen.

Irgendwie muss man diese einzelnen Tabellen-Dateien doch auch joinen können?

[DeddyH]

Wenn es wirklich um dBase geht (100% sicher scheint das nicht zu sein): ich mag mich irren, aber IIRC unterstützte dBase gar keine referentielle Integrität.

[Union]

Natürlcih geht ein Join auch ohne Schlüssel. Nur ist die Perfomance dann schlechter. Schau Dir mal den Advantage Local Server an.

[baurat]

Zitat:

Zitat von DeddyH (Beitrag 1123727)

IIRC unterstützt dBase gar keine referentielle Integrität.

... das muss ja auch gar nicht sein, um die kümmert sich (hoffentlich) das original-Programm, das die dbf-Dateien erzeugt. Es liegen zumindest die nötigen Informationen auf verschiedenen "Daten-Dateien" (sagt man das so?) verteilt, eben schon nach einem relationalen Schema organisiert.

Ich bin nur das "arme Schw....", das den Kram einlesen und aus den vielen verstreuten Einzelinformationen was Sinnvolles zusammenstellen muss... und immer noch hoffe, dass das über joins geht und ich mich nicht in ewiger Kleinarbeit mit Schleifen und lookups von Tabelle zu Tabelle hangeln zu müssen...

[mjustin]

dbase ist eine 'teilrelationale' Datenbank, sie unterstützt Joins (siehe http://viprex.de/gkinfo/datenbanken/db_befeh.html), aber eine Delphikomponente die es auch schafft einen Join auszuführen kenne ic noch nicht, in einem ähnlichen Fall (Clipper) half eine ODBC Treibersoftware, die einen eigenen SQL Dialekt unterstützte.

Man kann eventuell mit ClientDataSets und Master/Detail Abhängigkeiten einen Teil der zu Fuss Programmierung einsparen. Nachteil bei beiden (und auch bei ODBC Zugriff) ist, dass alle Datensätze in den Hauptspeicher geladen werden.

Falls nicht noch zufällig eine DBF Komponente oder ein O/R Mapper auftaucht, ist das 'Zu Fuss' in Objektlisten einlesen nicht die schlechteste Alternative - vorausgesetzt die Datenmenge ist absehbar im RAM unterzubringen.

[Sir Rufo]

"Wenn" es sich um Visual Foxpro handelt, dann einfach den Visual Foxpro ODBC Treiber installieren und dann per ADO darauf zugreifen.

Damit klappt dann auch das JOIN

[dataspider]

Zitat:

Zitat von Union (Beitrag 1123733)

Natürlcih geht ein Join auch ohne Schlüssel. Nur ist die Perfomance dann schlechter. Schau Dir mal den Advantage Local Server an.

Und es gab mal Delphi Komponenten:
TDataSet
Damit habe ich das immer gemacht.

Frank

[Singlepin]

Hast du dir schon mal die "Master Tabellen Beziehungen" in http://wiki.lazarus.freepascal.org/L...bf_Tutorial/de
angesehen? Das könnte dich weiterbringen.