Datenexport von Firebird nach Access über ZEOS

[waldforest]

Hallo,
ich nutze in meiner Application Firebird 2.1 und die Zeos-Komponenten.

Nun bin ich aber gefordert, einige Tabellen aus meiner Application nach ACCESS zu exportieren und komme da nicht wirklich weiter.
Idealer Weise würde ich dieses gerne über einen SQL-Befehl veranlassen, allerdings funktioniert dies nicht

hier mein Ansatz

INSERT INTO neueAccessQuery SELECT * FROM FireBirdQuery


Nach Excel habe ich bisher die JEDI´s genutzt, allerdings eine Komponente für ACCESS-Export gibt es nicht.

[Bummi]

Ich kenne mich leider weder mit Zeos noch mit Firebird aus, wenn Du den Umweg über Zeos >Oberfläche/Satzwiese> Ado nicht gehen willst, gibt es vielleicht eine Möglichkeit die Firebird Tabellen in eine Hilfsaccessdatenbank per ODBC einzubinden und dann per ADOCommand in der Art

PseudoCode:

Delphi-Quellcode:

insert into ZielDB.Tabelle Select * from HilfsDB.Tabelle

zu übertragen.

[mkinzler]

Oder auch per ADO auf Firebird zugreifen oder in Delphi die Daten von einem ins andere DataSet schieben

[waldforest]

Hallo,
ich komme trotzdem nicht weiter.
Ich habe die FirebirdDB über Zeos firebirdd-2.1, die Access über Zeos ADO Protokoll angebunden

Code:

FireBirdQuery.Active := True;
 conAccess.Connected := True;
  with zqryAccessDB do
  begin
    Active := False;
    SQL.Clear;
    SQL.Text := 'INSERT INTO Access_Table from FireBirdQuery';
    ExecSQL;
   end;
zqryAccessDB.Active := False;
conAccess.Connected := False;

Es erscheint die Fehlermeldung, dass FireBirdQuery.mdb nicht gefunden wird. Kann ja auch nicht, da es eine Tabelle aus der FB-Datenbank ist.

Wo ist mein Gedankenfehler ?

[mkinzler]

Kann so auch nicht gehen. CrossDatabase-Queries funktionieren nur in ADO.

[waldforest]

Hallo,
ich habe mein altes Problem noch einmal ausgegraben.

Nun habe ich den ODBC-Treiber für Firebird installiert,
so dass ich die Acess, und die Firebird beide über ODBC (ZeosQuery / ADO) verbunden habe.

Die Verbindungen zu den einzelnen Querys funktionieren, die Daten können in einem Grid sauber dargestellt werden.

Nun möchte ich die Daten der FirebirdDB in Access über einen SQL-Befehl importieren.

Code:

 FirebirdQuery.Active := True;
 conAccess.Connected := True;
 with AccessQuery do
  begin
    Active := TRUE;
    SQL.Clear;
    SQL.Text := 'INSERT INTO ACC_Table (art, name) SELECT art, name from FirebirdQuery';
    ExecSQL;
   end;

Erhalte aber eine OleException
Obwohl nun beide DAtenbanken über ODBC verbunden sind wird die Firebird beim Import nicht gefunden.


Microsoft[ODBC Microsoft Access Driver] Das Microsoft Jet Datenbankmodul findet die Eingangstabelle oder die Abfrage 'FirebirdQuery' nicht. Stellen Sie sicher, dass sie existiert und der Name richtig geschrieben wurde.


Ich verstehe nicht, warum diese Exception erscheint.
Hat jemenand keine Idee, was hier faklsch sein könnte ?

[Sir Rufo]

Weil du gerade ein Telefonkonferenz mittels 2 Telefonen machst.
Und nun wunderst du dich, dass der an Tel1 nicht versteht was der an Tel2 sagt.
Du hörst doch alles, dann müssten die doch auch alles hören.

Du musst die Werte schon selber von A nach B durchreichen, denn die Query wird ja direkt auf dem DBMS ausgeführt und dann kannst du auch nur das benutzen was da bekannt ist.
Alles dort Unbekannte musst du mitliefern.

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

Zitat von Piethan (Beitrag 1081403)

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.

[mschaefer]

Moin, moin, aus dem ersten Thread stammt der Wunsch

Zitat:

Idealer Weise würde ich dieses gerne über einen SQL-Befehl veranlassen ...

- ZEOS kann das derzeit nicht ( bleibt Eure Lösung über den Client )-
- BDE kann es auch von Interbase zu Access, aber veraltet Post #17 -
- FB kann direkt zu FB, Post #18 (ok andere gehen schlicht nicht).

PS: Jo hat das mit dem Joinen ja erwähnt, sehe ich auch so.

Grüße in die Runde

[jobo]

Vielleicht wurde das nicht deutlich, aber meine Testabfrage funktioniert sehr gut (ohne ZEOS) und sieht momentan so aus:

Code:

SELECT JOTB.ID, JOTB.IDTEXT, JOTB.LTEXT, JOTB.CDATE, JOTB.CUSER INTO ExportFromFirebird
FROM JOTB;

Wobei JOTB die Firebird Tabelle ist und EXPORTFROMFIREBIRD die Zieltabelle in der .MDB Datei.

Ein Join ist nicht notwendig, weil es keine Exporteinschränkung gibt, funktioniert aber bestimmt auch.

Ich weiß ja nicht, ob der TE es unbedingt über eine ZEOS Verbindung machen muss, aber notwendig ist es nicht. Vielleicht outet er sich ja noch mal.

Also neben den aufgeführten Varianten gibt es eine funktioniernde mittels Jet Engine.
EDIT: Bietet sich in dem Fall sowieso an, weil die Aufgabe ja darin bestand, nach ACCESS zu exportieren.