Hast du schon mal versucht, den Report mit einem execute block zu realisieren, in dem du dann per execute statement on external die daten der zweiten Datenbank holst. Aus der Sicht deiner Reportengine sollte das transparent sein, wenn die mit einem execute block in der
Query klar kommt, den du dann dort statt der Select Anweisung einträgst. Alternativ geht auch der Weg über Stored procedures, auch da geht execute statement on external, setzt aber fb25 voraus.
Hallo Holger, das habe ich noch nicht versucht, denn mir ist noch nicht so recht klar, was ein
execute statement on external genau ist.
1 GB und Groß - aber ich glaube das ist eine anderes Thema.
Klar ist 1 GB nicht wirklich viel. Doch im Vergleich mit den kaum 100 MB der Primär-
DB, die aber auch mit der Zeit wächst, ist da schon ein Größenunterschied.
Kannst du die Tabellen der zweiten
DB nicht per Linked Table (Weiß jetzt nicht wie das Richtig Wort hierfür bei Firebird heißt) einbinden so das es für den ReportGenerator so aussieht als würden alle Tabellen aus einer
DB kommen.
Von
Linked Table hab ich noch nie was gehört – bin ja auch nicht gerade der herausragende Firebird-Honk
Das Problem besteht nicht darin, überhaupt an die Informationen heranzukommen, sondern die Verarbeitungsgeschwindigkeit zu erhöhen. Die Selektion einer Datenmenge mit 85 Records, die ihre Zusatzinfo (5 Lookupfields) aus der anderen
DB holen müssen, dauert derzeit gut drei Minuten. Das ist unzumutbar. Für die Reporterstellung wäre das nicht so tragisch, aber beim Filtern und Suchen in der Tabelle, was wesentlich häufiger geschieht als der Report, ist diese lange Zeit schon ärgerlich. Die Reporterstellung selbst dauert dann seltsamerweise nicht mehr so lange, wohl weil die Abfragen aus der Zusatz-
DB zu diesem Zeitpunkt bereits erfolgt sind ... vermute ich mal ...
Hintergrund: Beim Einlesen der Daten (Logdateien) hat der Anwender die Möglichkeit, die Zusatzinfos gleich zuzuordnen. Sobald ein Datensatz in der
DB gespeichert wurde, wird der passende Datensatz aus der Zusatz-
DB herausgesucht und die jeweilige Id in der Haupttabelle der Primär-
DB gespeichert. Das geht recht flott, obwohl hierbei zwei Felder verglichen werden müssen. So dauert das Einlesen – wozu auch das Analysieren des Log-Eintrags gehört sowie die Überprüfung, ob ein Eintrag mit demselben Zeitstempel und demselben Dateinamen bereits existiert – von 1500 Einträgen kaum länger als 5 Minuten (geschätzt, nicht gemessen). Ich weiß nicht, woher diese lange Ausführungszeit beim Select-Befehl im
Query kommt. Momentan sind in dieser Haupttabelle knapp 310.000 Records, selektiert wird aber das entsprechende View in der Datenbank, weil das sowohl zur Darstellung im DBGrid als auch für den Reportgenerator benötigt wird. Je nach Select-Befehl (hätte ich vielleicht auch mit Filter machen können) dauert es bis zu 10 Sekunden, bis die Daten angezeigt werden. Auch das ist erträglich, müssen doch gegebenenfalls mehrere Spalten überprüft werden. Z.B. filtere mir alles vom 1.12. bis heute raus, das die Datei soundso beinhaltet, mit dieser Domain und jenem Result-Code. Aus den Einstellungen im Filter-Modul wird dann der
SQL-Befehl gebastelt. Seit ich nun diese Nachschlagefelder implementiert habe, dauert allein schon das Selektieren unerträglich lange, also bei jeder Änderung des Filters 3 oder mehr Minuten warten, bei größeren Datenmengen auch mal 15 bis 20 Minuten ...
Ich werde mir jetzt erstmal so behelfen, daß ich ein eigenständiges
Query für die erweiterte Reporterstellung einsetze und für die Darstellung im Grid einfach die Lookup-Fields weglasse. Heute aber wohl nicht mehr ...
Firebird erlaubt (bisher) nur in PL den Zugriff auf eine andere Datenbank. Linked Tables o.ä. werden m.W. nicht unterstützt.
Was ist PL?
Nachtrag: Dem Reportgenerator dürfte es egal sein, ob die Daten aus einer oder aus mehreren Datenbanken stammen, denn die Daten werden ja über eine TRvDataSetConnection bereitgestellt. Ich bin mir auch nicht sicher, ob die beschriebene Verzögerung tatsächlich mit der Verwendung einer zweiten Datenbank zusammenhängt.