Fastreport: Beim zweitenmal leerer Report

[MrSpock]

Hallo,

habe einen Fastreport. Er benutzt 3 Datasets, die über die Eigenschaft frxDBDataset.Dataset mit 3 frxDBDataset Komponenten verbunden sind.

Dann werden die 3 Datasets (Queries) aufgesetzt und geöffnet. Dann der Report angezeit (ShowReport(True)). Funktioniert alles.

Dann schließe ich den Brericht über die Schließen - Taste aus FR.

Dann wähle ich andere Datensätze und durchlaufe dieselbe Procedure, die die 3 Firedac Datasets mit neuen SQL Statements erstellt und wieder öffnet.
An den frxDBDatasets mache ich nichts.

Der FR wird geöffnet, aber ist immer leer.

Was muss ich machen, damit der Report wieder Daten anzeigt. Die Datasets sind definitiv nicht leer.

Muss ich noch irgendwas mit den frxDBDataset Komponenten machen oder hat jemand eine andere Idee, woran das liegen könnte?

[Hansa]

Du willst einen Report anzeigen/drucken und brauchst dafür dann 3 Datasets ? Das muss jetzt mal erklärt werden, wo da der Sinn liegen soll.

[Sir Rufo]

Zitat von Hansa:

Du willst einen Report anzeigen/drucken und brauchst dafür dann 3 Datasets ? Das muss jetzt mal erklärt werden, wo da der Sinn liegen soll.

In den 3 DataSets befinden sich die Daten, die er darstellen will.

Und damit sind wir wieder zurück beim eigentlichen Thema.

Welche FastReport Version ist denn im Einsatz?

[MrSpock]

Es ist FR 5.0 VCL und es ist eine Rechnung, die einen Master-Detail Bericht darstellt.

Ich habe es aber gerade gelöst. Es lag mal wieder zwischen den Ohren:

In der DetailQuery nutze ich die Eigenschaft MasterSource. Diese nutzte ein Formular, was nach dem ersten Ausdruck freigegeben wurde. Damit war Mastersource zumindest nicht mehr richtig gesetzt und die Detail Datenmenge war leer.

[frankyboy1974]

fascinating

[Hansa]

Meine Frage zielte eher darauf ab, wie man Fehlerquellen minimiert. Ich selber versuche, solche Dinge eher die DB machen zu lassen. Sprich : mehr Logik in die DB zu stecken, um eben zu verhindern, dass so Zeugs wie mehrere Datasets, oder Master-Detail benutzt werden müssen. Das ist fehlerträchtiger als ein längeres SQL oder eine Stored Procedure anzulegen, die dann als einziges Dataset angesprochen werden kann. DBGrid und Co. sehen auf den ersten Blick vielleicht verlockend aus, machen aber IMHO mehr Ärger, als sie wert sind.

Also pro Report ein Dataset mit allen Daten, die auf den Report sollen. Für eine Rechnung baue ich mir deshalb eine SP, die sich alles zusammensucht und z.B. in IBExpert schnell getestet werden kann. Geht die zufriedenstellend, dann wird das alles in Delphi eingebaut und fertig. Das eine Dataset ist dabei aber nicht so streng zu nehmen. Einzelne Felder können natürlich auch von anderem Dataset kommen und in ein DBText. Wobei ich trotzdem da lieber ein TLabel nutzen würde. Eventuelle Fehler fallen da einfach früher auf und lassen sich besser lokalisieren.

[MrSpock]

Hallo Hansa,

ich arbeite bei den Rechnungen, mit den Rechnungskopfdaten und den Positionen. Habe ich z.B. 30 Positionen (kommt oft vor), erzeuge ich ja die Kopfdaten dann 30 mal. Ob das wirklich effizienter ist? Auch in der Anwendung zeige ich dem Nutzer zunächst nur die Kopfdaten und er kann sich durch diese navigieren. Die Positionsdaten werden dann über Master - Detail einfach passend abgerufen.

Ich stimme aber zu, dass es Berichte gibt, in denen eine einzelne Datenmenge sinnvoller ist als eine Master-Detail Verknüpfung.

[Hansa]

Ah ja, verstehe. Du bist ja, glaube Schwabe. Ne, im Ernst : wenn ich den Kopfdatensatz im Zugriff habe und dazu die Positionen nachlade, egal ob über Db-sensitive Komponenten oder von Hand in Labels/Edits ist wohl egal.

Aber meine Erfahrung sagt mir auch folgendes : eine SP die gegenüber einem einzelnen Datensatz eben 30 Datensätze auf einmal liefert, kann wesentlich schneller sein, als DB-Komponenten, die eventuell für den Zweck irgendwelche unnütze Zeit verbrauchen bzw. sogar nur einen Datensatz liefern.

[MrSpock]

Wahl-Badener, ich habe aber auch mit Wahl-Schwabe kein Problem .