Tabellen aus verschiedenen Datenbänke in einem DBGrid

[erich.wanker]

Hallo,
wie kann ich in einem Grid Daten aus zwei Datenbänke darstellen?


Tabelle1 ist in beiden Datenbänken vorhanden und hat TEILWEISE gleiche Felder!

Database1 - Tabelle1 hat Felder: INR (unique Integer key) Eintrag (String) Bemerkung (String) Messwert (double)
Database2 - Tabelle1 hat Felder: INR (unique Integer key) Eintrag (String) Bemerkung (String) Baugruppe(String)

Jetzt will ich die "gemeinsamen Felder" - die beide Tabellen aufweisen in einem Grid darstellen.

ZConnection1 -> Database1.fdb -Tabelle1
ZConnection2 -> Database2.fdb -Tabelle1

ZQuery1.Connection:= UniMainModule.ZConnection1
ZQuery2.Connection:= UniMainModule.ZConnection2

ZQuery1.SQL.Clear;
ZQuery1.sql.append(' SELECT ???? INR,EINTRAG,BEMERKUNG from ????

UND
Wenn ich in DbGrid einen doppelklick auf einen Eintrag mache - wie erkenne ich ob ich nun einen Record aus Database1 oder Database2 habe?

[stifflersmom]

Sind beide Datenbanken auf dem selben Server und greifen da dieselben Credentials?

Dann könntest Du da vielleicht schon mit einer Query erschlagen:

select t1.spalte1, t2.spalte1, t1.spalte2, t2.spalte2
from dbname1.tabelle t1, dbame.tabelle t2
where t1.id=t2.id

[hoika]

Hallo,

Zitat:

wie erkenne ich ob ich nun einen Record aus Database1 oder Database2 habe

Select 1, Name From DBName1.Tab1
Union
Select 2, Name From DBName1.Tab2

https://firebirdsql.org/manual/ufb-cs-multidb.html

DBName1.Tab1 war ein Test

[Uwe Raabe]

Wäre hier nicht eher eine UNION das Mittel der Wahl?

Zitat:

Ein UNION verkettet zwei oder mehr Datasets und erhöht so die Anzahl der Zeilen, nicht aber die Anzahl der Spalten. Datasets, die an einer UNION teilnehmen, müssen die gleiche Anzahl von Spalten haben, und Spalten an entsprechenden Positionen müssen vom selben Typ sein. Abgesehen davon können sie völlig unabhängig sein.

[hoika]

Hallo,
mit Union kann man aber nicht verschiedene DB's verknüpfen,
siehe mein Link.

Es sei denn, FB kann das mittlerweise.
FB2.5: http://www.firebirdfaq.org/faq16/

Aber: Wird reden hier ja von FB2.1.

[himitsu]

Kann FireDAC nicht auch LocalSQL auf GUI-Komponenten?
Dann ein SELECT das aus die zwei anderen QueryComponenten geht.

Datenbank übergreifend (im selben DB-Server) sollten alle DBMS können.
Einige DBMS bieten auch Funktionen, um serverseitig auf einen anderen DB-Server (sogar auf komplett andere DBMS) zuzugreifen.

[TRomano]

Da Firebird es nicht kann wird dir wohl nichts anderes übrig bleiben, beide Queries zu öffnen und in eine definierte Struktur eines ClientDataSets zu laden.
Dort kannst du ein zusätzliches Feld anlegen mit dem Namen woher die Daten stammen. Da ClientDataSet kannst du mit einem TDataSource verbinden und die Komponente wiederum mit deinem Grid.
Umständlich, aber es geht.Nur wenn Du dann im Grid auch noch Ändern/Erfassen/Löschen willst wird es tricky ...

[hoika]

Hallo,
wenn eh alles so umständlich ist,
kann er ja gleich ein normales TStringGrid nehmen
und die Update-Methoden über eigene Queries machen, je eine pro DB.

[jobo]

Man sieht, es ist nicht vorgesehen. Dann sehe ich da noch in den verschiedenen DB die Definition / Nutzung von eindeutigen Feldern.
Ein Sinn einer DB ist es ja, der Anforderung "unique" einen Rahmen zu geben und diesen einzuhalten.
Paart man 2 DB, so ist es nichts mehr mit Eindeutigkeiten.

Da sollte doch die Frage erlaubt sein, was eigentlich der Sinn der Aktion sein soll.

[himitsu]

Wie sollen die eigentlich zusammen?
Untereinander (UNION) oder nebeneinander (JOIN).
[edit] OK, soll untereinander.

Beim JOIN können die Felder des zweiten DataSets als CalcFields an das Andere angehängt werden.
Aber beim UNION bleibt nur das Umkopieren, in ein MemoryDataSet (z.B. TClientDataSet), bzw. direkt in ein nicht-datensensitives Grid.
Für's LiveBinding gibt es bestimmt noch elegantere Wege, vor allem da dort eh das DataSet über eine Liste umgeleitet wird.

Zitat:

wie erkenne ich ob ich nun einen Record aus Database1 oder Database2 habe?

Über eine zusätzliche Spalte, in der das drin steht? :zwinker:
(kann auch ausgeblendet sein und für die Hintergrundfarbe der Zeilen genutzt werden)


Für den JOIN hätte man bestimmt auch die NestedDataSets missbrauchen können.
https://edn.embarcadero.com/article/29825

@faq16: Man, muß der Kleine schon alt sein.
Fehlt ja nur noch dass "You cannot do JOINs with tables in different database" behoben wird.

https://stackoverflow.com/questions/...-fdb-databases
Das Ding lässt sich aufrufen und in mehrere Variablen schreiben.
Also Zeile für Zeile in einer StoredProc aus der anderen Datenbank holen und an das erste Select anjoinen? :lol:
https://firebirdsql.org/rlsnotesh/rn...exctstmnt.html

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