Tabellen aus verschiedenen Datenbänke in einem DBGrid

[hoika]

Hallo,

Zitat:

Also Zeile für Zeile

Stein für Stein, so wurden auch die Pyramiden gebaut.
OK, es waren etwas größere Steine ...

[MyRealName]

Der Zugriff ist doch auf Firebird, da kann man doch innerhalb eines SQL Abfragen auf andere Datenbanken machen, von daher war die Lösung von Uwe Raabe schon richtig. Es sollte mit einem UNION SELECT gehen, wobei einer auf die DB der Verbindung zugreift und der 2. SQL auf die andere DB zu. Da gibt es den Befehl ON EXTERNAL SOURCE

Code:

ON EXTERNAL DATA SOURCE <Database name> AS USER <Username> PASSWORD <Password>'

[himitsu]

Zitat:

Zitat von MyRealName (Beitrag 1455786)

Es sollte mit einem UNION SELECT gehen

Zitat:

You cannot do JOINs with tables in different database

http://www.firebirdfaq.org/faq16/ :zwinker:

Gut, versuchen geht über studieren.
Manchmal ist auch nur die Hilfe falsch und der Code geht dennoch.

[hoika]

Hallo,
https://firebirdsql.org/refdocs/lang...-execstat.html
Dort suchen nach
ON EXTERNAL [DATA SOURCE]
Added in: 2.5

Das geht aber erst ab FB2.5, wir reden von FB2.1.
Und es geht nicht mit einem normalen Select (glaube ich).
Man könnte das natürlich in eine SP machen (steht auch auf der Seite)

[p80286]

Zitat:

Can I do multi-database or cross-database queries with Firebird?

Short answer: You cannot. Firebird 2.5 introduces some basic support though...

The only way is to pump the data from one to another using tools like IBDataPump, FBCopy, FBExport, or some of administration tools that have this option. See FAQ #20 for details.

You can, however, do the multi-database transactions: have a one transaction that reads and changes data in multiple database. Firebird's ACID compliant and ensures that this is possible.

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.

(siehe http://www.firebirdfaq.org/faq16/)

Mach für jede DB je eine Connection und eine Query, und pack die Ergebnisse in ein normales Stringgrid.
Das ist einfacher und sicherer als die angestrebte Lösung.
Oder leg eine dritte Datenbank an, die aus den Daten der beiden anderen gespeist wird, oder leg in der einen DB zusätzliche Tabellen an, die aus der anderen DB gefüllt werden. Alles kein Hexenwerk und mit jedem DBMS zu realisieren.


Gruß
K-H

[MyRealName]

Bei den UniDAC Komponenten (ich weiss, dass der TE ZEOS nimmt) gibt es noch das VirtualQuery, wo lokales Sqlite genutzt wird und man abfragen über verschiedene Datasourcen gemacht werden können. auch 'ne coole Sache

[haentschman]

Moin...8-)

Zitat:

wenn eh alles so umständlich ist,

[meine Meinung / Vorschlag]
Ich bin Verfechter einer Zwischenschicht die die Querys, oder andere Datenquellen, in Objekte wandelt. Beim Zusammenbauen des Objektes in der Zwischenschicht ist dann egal wo die Daten herkommen. (Datenbank, CSV, Omas Küchenschrank und wenn gewollt, auch gemischt).
Die Anwendung als solches arbeitet nur mit den Objekten. Damit ist es auch möglich, durch den Austausch der Zwischenschicht, z.B. die Anwendung auf REST umzubauen.
[/meine Meinung / Vorschlag]

:wink:

[Uwe Raabe]

Zitat:

Zitat von MyRealName (Beitrag 1455812)

Bei den UniDAC Komponenten (ich weiss, dass der TE ZEOS nimmt) gibt es noch das VirtualQuery, wo lokales Sqlite genutzt wird und man abfragen über verschiedene Datasourcen gemacht werden können. auch 'ne coole Sache

Für FireDAC hätte ich analog dazu LocalSQL in den Ring geworfen, aber es ist nun mal eben ZEOS.