Datenexport von Firebird nach Access über ZEOS

[jobo]

Ich hab auch kein Firebird und kein Zeos, aber ich stelle mir das so vor:

Du nimmst eine Access.mdb (mglw. gleich die Ziel DB),
dort kommt per ODBC eine Tabellenverknüpfung zur Firebird Quelltabelle rein.

Dann baust Du direkt in Access (mit Hilfe des Assistenten) die Insert Abfrage, nimmst Dir die SQL Anweisung und verwendest die dann in Delphi.

In Delphi brauchst Du für diesen Schritt nur eine ADOConnection via Access/ Jet Engine zu der Access DB von oben und eine ADOQuery für das SQL Statement, kein Firebirdzugriff, das soll die Jet Engine machen.

Könnte funktionieren.

[mschaefer]

Für die BDE gibt es eine Möglichkeit mehrere BDE-Aliases zu definieren und die dann direkt in der SQL anzusprechen. Das Durchreichen der Werte ist damit nicht erforderich. Laut Hilfe gibt es auch sowas für ADO, aber ich finde im Moment kein Beispiel dafür. Die Stichwörter zum Suchen sind "supports heterogeneous queries". Bei mir ist jetzt allerdings "Computer ShutDown".

Grüße in die Runde

[Piethan]

Hi,

ich würde hier wie folgt vorgehen. Die Source auslesen und zeilenweise an deine AccessDB weiterreichen,
praktischer weise solltest du auch die Daten prüfen z.B. mit RegExpr und nur die importieren welche richtig
sind.

Delphi-Quellcode:

while not fbDataSet1.Eof do
begin
  try
    dtsAccess.fieldByName('NAME').asstring:=fbDataset1.FieldByName('NAME').AsString;
    dtsAccess.Post;
    fbDataset1.Next;
  finally
    
  end;
end;

LG
Dirk

[Sir Rufo]

Vor dem Schreiben sollte aber ein Edit kommen bzw. Hier ein Append.

Allerdings ist es geschickter dieses über ein SQL-Skript mit Parametern zu lösen.
Ein TDataSource mit der Firebird-Query verbinden.

Diese DataSource bei der Access-Query als MasterSource definieren.
jetzt kann man alle Felder aus der Firebird-Query in der Access-Query als Parameter ansprechen.

Code:

INSERT INTO ACC_Table (art, name) VALUES( :art, :name )

Jetzt die Firebird-Query öffnen und jeden Datensatz durchlaufen und bei jedem die Access-Query einmal ausführen lassen.

[Piethan]

Ist es dann nicht performanter das SQL komplett aufzubauen und erst dann auszuführen?

Delphi-Quellcode:

COUNT=0
while not fbdb.eof do
  begin
   qryaccess.sql.add(INSERT INTO ACC_Table (art, name) VALUES( fbdb.fieldbyname('art').asinteger, fbdb.fieldbyname('name').asstring);
   fbdb.next;
   COUNT=COUNT+1;
     if COUNT = 1000 then
      begin
        COUNT=0;
          qryaccess.sql.add('commit;'); // so gehen nicht alle Datensätze verloren, wenn ein Fehler auftritt
      end;
   end;
qryaccess.execSQL;

[Sir Rufo]

Kommt immer auf das Framework und DBMS an.

Ein Prepared Statement in einer Transaction sollte sehr schnell sein.
Muss das DBMS aber auch alles unterstützen und bei Access nun ja.

[Bernhard Geyer]

Zitat von Piethan:

Ist es dann nicht performanter das SQL komplett aufzubauen und erst dann auszuführen?

Nein. Schneller ist es eine parametrisierte Abfrage zu verwenden die man prepared.

Delphi-Quellcode:

COUNT=0
qryaccess.sql.add(INSERT INTO ACC_Table (art, name) VALUES(:param1, param2);
qryaccess.prepare;
while not fbdb.eof do
  begin
   qryaccess.paramByName('param1').asInteger := fbdb.fieldbyname('art').asinteger;
   qryaccess.paramByName('param1').asString:= fbdb.fieldbyname('name').asstring;
   qryaccess.execute;
   fbdb.next;
   ...
 end;
qryaccess.execSQL;

Commit/Rollback kann man sich eigentlich bei Access sparen da diese Datenbank das nicht korrekt durchführt. Ein Programmabsturz führt (vor Jahren mit Acc2000 getestet) dazu das auch uncommited-Datensätze gespeichert wurden.

[waldforest]

Hallo,
danke für die Tipps.

Ich habs nun über die Parameter realisiert.
Läuft auch bei ca. 40 tausend Datensätzen noch in einem vetretbaren Zeitrahmen.