Datenexport von Firebird nach Access über ZEOS

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

[jobo]

Aus lauter Neugier:
Wie schnell ist denn "vertretbar"?
Ich habe meinen Vorschlag (ohne ZEOS) gerade ausprobiert und mir Firebird installiert. Mit einer Testtabelle, die ich mit 65T Datensätzen befüllt hab, braucht der Export nach Access (bestehende mdb, aber neue Tabelle) ca 5 Sekunden. Alle Daten sind dabei lokal auf dem Laptop.

[mschaefer]

Sowas wie für die BDE soll es laut Dr. Bob auch für ADO geben, dann
kann man tatsächlich Abfragen in eine SQL legen. Nur die Beispiele fehlen.

Zitat:

Note: The Borland Database Engine (BDE) has been deprecated, so it will not be enhanced. For instance, BDE will never have Unicode support. You should not undertake new development with BDE. Consider migrating your existing database applications from BDE to dbExpress.
TQuery supports heterogeneous queries against more than one server or table type (for example, data from an Oracle table and a Paradox table. When you execute a heterogeneous query, the BDE parses and processes the query using Local SQL. Because the BDE uses Local SQL, extended, server-specific SQL syntax is not supported.

To perform a heterogeneous query

1.Define separate BDE aliases for each database accessed in the query using the BDE Administration tool or the SQL explorer.
2.Leave the DatabaseName property of the TQuery blank; the names of the databases used will be specified in the SQL statement.
3.In the SQL property, specify the SQL statement to execute. Precede each table name in the statement with the BDE alias for the table's database, enclosed in colons. This whole reference is then enclosed in quotation marks.
4.Set any parameters for the query in the Params property.
5.Call Prepare to prepare the query for execution prior to executing it for the first time.
6.Call Open or ExecSQL depending on the type of query you are executing.
For example, suppose you define an alias called Oracle1 for an Oracle database that has a CUSTOMER table, and Sybase1 for a Sybase database that has an ORDERS table. A simple query against these two tables would be:

SELECT Customer.CustNo, Orders.OrderNo
FROM ":Oracle1:CUSTOMER"
JOIN ":Sybase1:ORDERS"
ON (Customer.CustNo = Orders.CustNo)
WHERE (Customer.CustNo = 1503)
As an alternative to using a BDE alias to specify the database in a heterogeneous query, you can use a TDatabase component. Configure the TDatabase as normal to point to the database, set the TDatabase.DatabaseName to an arbitrary but unique value, and then use that value in the SQL statement instead of a BDE alias name.

Grüße in die Runde

[mschaefer]

Von Firebird zu Firebird-Database geht über eine Stored-Procedure:

Zitat:

Firebird 2.5 introduces a way to query the external data sources in PSQL. EXECUTE STATEMENT has been extended with a special clause: ON EXTERNAL DATA SOURCE, and you can supply a different Firebird database as a data source. This means that you can fetch data from another database into PSQL variables. You cannot do JOINs with tables in different databases, but this is a nice start. Example:

execute block returns (emp_no smallint) as
begin
FOR EXECUTE STATEMENT 'select emp_no from employee'
ON EXTERNAL DATA SOURCE 'localhost:employee' AS USER 'sysdba' PASSWORD 'masterkey'
INTO :emp_no
DO SUSPEND;
end

As you can see, using aliases becomes important and there is still a lot to be desired, but it's enough to cover some of the most basic needs.

Grüße in die Runde

[Sir Rufo]

In Post #17 vermisse ich den Bezug zum ADO im Zitat und Post #18 ist hier irgendwie OT

Oder ich verstehe nicht was du uns damit sagen möchtest

[jobo]

ich vermute, dass

Zitat:

"..as an alternative to using a BDE alias to..

die Hoffnung beflügelt hat. Das Wort "alias" ist da wohl untergegangen..


zu #17

Die Jet Engine macht ja genau das, was die BDE macht. Die Verdrahtung der Datenqellen erfolgt innerhalb einer ACCESS.MDB. Das Datentransferstatement, das dann von Delphi angestoßen werden kann, also sowas wie

Code:

insert into [heterogene tabelle A] (fields)
select fields from [heterogene tabelle B]
where usw...

benötigt nur den ADO Zugriff auf ACCESS.

Dabei hat man sich unter Delphi sämtliche FIELDBYNAME Aktionen, Parametrierung usw. gespart. Ich vermute, dass es auch schneller ist, daher auch meine Frage in Post #16.

P.S.: Man sollte auch prima Joinen können, wenn man im Hinterkopf behält, dass es eine heterogene Abfrage ist.