Crystal Reports XI + Delphi und unterschiedliche Datenbanken

[cytrinox]

Zitat von Bernhard Geyer:

Jedes vernünftige Reportingtool kann auch ohne "normales" Dataset arbeiten, sprich man kann den Report mit "virtuellen" Datasets befüllen.

Kann ich ja, mach ich ja. Genau das realisieren die TCrpeDS Komponenten. Aber die sind eben langsam.. SEHR LANGSAM.

Und da es über SQL schneller geht, brauch ich ne SQL Schnittstelle...

[Bernhard Geyer]

Zitat von cytrinox:

Kann ich ja, mach ich ja. Genau das realisieren die TCrpeDS Komponenten. Aber die sind eben langsam.. SEHR LANGSAM.

Ok, hab noch mal den entsprechenden Abschnitt gelesen. Jetzt wirds komplizierter ...
Evtl. wären Hilfsview als virtueller DS hilfreich die diesen INNER JOIN schon realisiert haben?

[cytrinox]

Noe, denn ich weiß ja nicht was für Verknüpfungen der Report braucht.

Ich weiß ja nicht, ob du mit CR schonmal gearbeitet hast, aber um dort z.B. einen INNER JOIN zu erstellen, geht man in die Datenbankverwaltung rein, da hat man z.B. seine zwei Tabellen und zieht das eine zu verknüpfende Feld auf das der anderen Tabelle - genauso wie z.B. bei Access.

Ich kann bei den TCrpeDS Komponenten nicht mehr machen also zu sagen:


CrpeDS1.connection := myZconnection;
CrpeDS1.sql("SELECT * FROM tbl_1");
CrpeDS2.connection := myZConnection;
CrpeDS2.sql("SELECT * FROM tbl_2");

CrpeViewer.open(report.rpt);

CrpeViewer.tableByName(tbl_1).datapointer := crpeDS1.datapointer;
CrpeViewer.tableByName(tbl_2).datapointer := crpeDS2.datapointer;

Damit bekommt CR zwei komplette Resultsets und muss diese anhand der im Report hinterlegten verknüpfung selbst ausrechnen.


Mit einer SQL fähigen Schnittstelle hängt man einfach die Datenbankverbindung an das CrpeVier Object, z.b. eine ODBC Verbindung, CR sieht er hat eine SQL Datenbank zu Verfügung, erzeugt einen SQL INNER JOIN, schickt das an die Datenbank und das eine Resultset dass es bekommt wir einfach nur noch ausgedruckt.


Es sollte dir wohl klar sein, dass erste Methode länger dauert, zum einen weil die ganzen datenbankspezifischen Optimierungen wegfallen, die ein Datenbanktreiber hätte, zum anderen weil auch Datenstätze geholt werden, die z.B. keinen passenden verknüpften Datensatz in der zweiten Tabelle enthält und CR die dann selbst "wegwerfen" muss.



(Den Code soll jetzt kein Delphicode sein sondern nur die Vorgehensweise verdeutlichen )

[Bernhard Geyer]

Ok, damit wird mir klar was CR macht und wo der vermutlich Mangel von CR in diesem Fall ist.

CR wird einfach für jeden Datensatz aus DS1 einen Full-Table Scan in DS2 durchführen. Besser wäre es wenn er sich indern einen Index auf DS2 anlegt (im Speicher) und dann genau die gleichen Optimierungen wie bei einer "richtigen" Datenbank durchfühen würde. CR weiß ja welche Spalte Indiziert werden müssen.

Zu deinem ODBC-Treiber: Welches DBMS willst du denn "Faken". Du mußt ja ein von CR unterstützten DBMS nachbilden damit CR die Queries dafür optimieren kann (z.B. INNER JOINs werden bei jeder Datenbank Syntax-Technisch anders aufgebaut).

[cytrinox]

Zitat von Bernhard Geyer:

Zu deinem ODBC-Treiber: Welches DBMS willst du denn "Faken". Du mußt ja ein von CR unterstützten DBMS nachbilden damit CR die Queries dafür optimieren kann (z.B. INNER JOINs werden bei jeder Datenbank Syntax-Technisch anders aufgebaut).

Ah, endlich kommen wir weiter

Das hab ich ja auch in meinen "Fragenkatalog" oben reingeschrieben.

CRXI hat datenbankspezifische Treiber mit dabei, also z.b. für Access, Oracle, Paradox usw.
Aber man hat natürlich auch die Möglichkeit über ODBC oder JDBC zu gehen.

In dem Fall muss ja nur ein ODBC Treiber in Windows registriert sein, der wird dann über die ODBC-Unterstützung von CR angesprochen.

Ich muss also kein DBMS "nachbilden", sondern einfach nur einen ODBC Treiber zu verfügung stellen.
Aber genau hier komme ich auf die selbe Frage wie du: Wie sag ich CR wie z.B. ein INNER JOIN aufgebaut sein muss?
Ich denke, dass das irgendwie der ODBC Treiber vorgeben muss, nur weiß ich noch nicht wie. In der Doku von Microsoft hab ich diesbezüglich noch nichts gefunden.
Darum hab ich die Frage ja auch hier reingeschrieben

[Bernhard Geyer]

Zitat von cytrinox:

Ah, endlich kommen wir weiter

Wird sich zeigen.

Zitat von cytrinox:

Aber genau hier komme ich auf die selbe Frage wie du: Wie sag ich CR wie z.B. ein INNER JOIN aufgebaut sein muss?

CR liest aus dem ODB-Eintrag den Treibernamen und bekommt dann MS SQL Server, Oracle etc. und wendet dann die fest im CR implementierten Regeln an. Wenn du mit einem Ungekannten Namen kommst so wird (vermutlich) CR das gleiche machen wie bei den "virtuellen Dataset". Außer du hast guten Kontakt zu Seagate und sagst das der neue Treibername "MeinSuberFakeTreiber" die gleichen Regeln hat wie ein MS SQL Server. In ODBC sind keine Funktionen definiert womit man sowas abfragen kann.

[cytrinox]

Dem kann ich nicht ganz zustimmen.

Ich hab mir den Firebird ODBC Treiber mal runtergeladen, bei einem meinen Reports die Verbindung gegen ODBC ausgetauscht (das geht im Designer zum Glück extrem einfach) und einen Testlauf gemacht, das klappt wunderbar.

Edit: Wen man das ein Stück weiterdenkt könnte man im Notfall ja sagen man legt im ODBC Treiber z.B. MSSQL oder INTERBASE fest und hängt in der Applikation einen Parser dazwischen der das Statement nochal durchgeht und dann erst an die Datenank schickt. Das werden wir wohl eh machen müssen, da wir z.Z. nur mit Zeos und Firebird arbeiten. Die Frage ist ja, ob unsere Statements, die wir direkt im Programm verwenden, auch mit anderen Datenbanken laufen - ich denke nämlich Zeos hat da keinen eigenen Parser der das auf die ausgewählte Datenbank umschreibt.

[Gremlin]

Den SQL bekommst du doch vom Report geliefert über die Property SQL und einem Retrieve, die ungefähr so aussieht

SQL-Code:

SELECT
    AUFTRAG."NR", AUFTRAG."KUNDENNR", 
    AUFPOS."NR", AUFPOS."POSNR", AUFPOS."ARTIKELNR"
FROM
    { oj "AUFTRAG" AUFTRAG INNER JOIN "AUFPOS" AUFPOS ON
        AUFTRAG."NR"=AUFPOS."NR"}
WHERE
    AUFPOS."NR" < 10000

Wenn du mit dieser etwas anfangen kannst und du daraus deine eigenen Datasets füllen kannst.
Eine Auswahl welche Datensätze ermittelt werden sollen, kannst du direkt über die Selection bzw.
GroupSelection auslesen.

Der genauere Syntax, den CR beim Erstellen der SQL's verwenden soll, ist in der Registry
eingestellt, weiss es aber nicht mehr wo genau.

[cytrinox]

Das geht aber nicht bei der Verwendung von den TCrpeDS Komponenten. Da die für CR keine SQL-Schnittstelle anbieten, wird auch kein SQL String erzeugt.

Dass der Syntax in der Registry festgelegt wird bezweifle ich auch (aber kann ja sein). Dass der ODBC Treiber einen Namen ausspuckt und dieser Name im CR mit einer Snytax-Definition verbunden sein muss erscheint mir da schon logischer.