Reports allgemein Datentrennung

[Der schöne Günther]

Habe ich bislang immer so gemacht- Der (Fast-)Report bekommt eine Handvoll (Array, IEnumerable) Objekte, kein TDataSet oder sonst was. Das kann er sich dann in sein TFrxUserDataSet legen um dadurch zu iterieren oder sonstwie verwursten. Ich sehe ehrlich gesagt auch keinen Grund weshalb der Report (Anzeige) selbstständig in irgendwelchen Daten rumwühlen sollte.

Wenn der Kunde selbst aber schon eine fertige Datenbank bereitstellt und von der Software auch noch erwartet, die Reports (zu speziell dieser Datenbank) etwas anpassen zu können, dann habe ich da ehrlich gesagt keine Hemmungen.

[p80286]

Kommt darauf an wie Du "Report" definierst. In den allermeisten Fällen sollte es schon richtig sein, daß da eine Sammlung von Datensätzen geliefert wird, die der "Report" aufhübscht. Wenn aber der Report aus Serienbriefen besteht wo zu einer Person 1..ganz viele Datensätze die auch noch bis zu 4 unterschiedliche Strukturen haben können, dann ist es effizenter wenn der "Report" sich seine Daten selbst holt. Sonst müßtest Du eine riesige Tabelle zur Verfügung stellen, aus der sich der Report mühsam die Daten für den jeweiligen Fall heraus klauben müßte. Und das macht ganz wenig Spaß.
Was ist jetzt daran soo schlimm ist, daß der Report die Quell-DB kennt?
Die Daten werdennatürlich von einem View und oder einer Funktion geliefert, und das Login erfolgt auch nur über eine "dumme" UID.

Gruß
K-H

[mm1256]

Hallo,

einen Report physikalisch unabhängig von einer Datenbank oder einer sonstigen Datenquelle zu erstellen, ist eigentlich ein alter Hut. Zumindest bei List&Label den ich schon seit etwa 18 Jahren verwende.

Man deklariert hier seine Variablen und Felder für den Ausdruck manuell. Woher die Daten kommen, ist dem Report total egal. Das kann prinzipiell alles sein. Diese Unabhängigkeit (und natürlich die damit verbundene Flexibilität) ist bzw. war für mich auch damals das entscheidende Argument für den Einsatz von List&Label.

Natürlich gibt es auch Datenbanksensitive Komponenten, mit denen man dann auf die Schnelle einen Report über einen oder mehrere Tabellen erstellen kann. Aber, das habe ich noch nie verwendet, weil ich eben die Flexibilität schätze, und auch anwende.

Ein Beispiel: Bei TDateTime-Feldern deklariere ich diese für den Report natürlich als entsprechende Variable, und zusätzlich davon noch als numerische Variable Jahr, Monat, Tag, Stunde und Minute. Wenn ein Kunde dann beispielsweise einen Report über alle Rechnungen in einem Jahr/Monat/Tag erstellen möchte, wählt er einfach den entsprechenden Filter, und ich muss keine "abenteuerlichen" SQL-Statements schreiben

[Sir Rufo]

Man kann mit FastReport eben beides machen:

Der quick&dirty Bericht mit direktem Zugriff auf die Datenbank
oder eben mit einem Datenpaket (wie auch immer geartet).

Der Vorteil bei so einem Datenpaket liegt eben in der Trennung von der konkreten Datenbank.

Nimmt man an der DB Änderungen vor, dann funktioniert der Report immer noch (wenn man das Datenpaket erstellen kann).
Den Report kann man auch ohne DB testen/designen (einfach ein Datenpaket unterjubeln).

[Dejan Vu]

Die Option bietet dem Kunden einfach mehr Flexibilität. Und ehrlich gesagt: Mir auch. Ich muss nämlich das Reportingmodul nicht erweitern, wenn die DB verändert bzw. erweitert wurde.

[mm1256]

Zitat von Dejan Vu:

...Ich muss nämlich das Reportingmodul nicht erweitern, wenn die DB verändert bzw. erweitert wurde.

Richtig, "müssen" musst du nicht, aber dann beinhalten deine "alten" Reports natürlich nicht die Erweiterungen der DB. Und spätestens da trennt sich meiner Meinung nach die Spreu vom Weizen bei den Report-Generatoren. Denn um Reports beim Kunden aktuell zu halten, müssen diese auch programmtechnisch (also mit einfachem Delphi-Code) erweitert werden können.

Mit L&L kann ich per DOM die alten Reports beim Kunden an die neuen Inhalte anpassen. Auch die Reports die der Kunde selber (mit dem mitgelieferten Formulardesigner) erstellt hat, deren Inhalt bzw. Aufbau/Struktur ich demzufolge gar nicht kenne. Unabhängig von der Programm-Version, d.h. ich kann ohne die Report-Version zu kennen einen beliebig alten Report auf eine aktuelle Version - mit allen Erweiterungen der DB - hochziehen. Das geht es bei jeder Änderung/Neuerung um eine Zeitersparnis in der Größenordnung von einigen hundert Stunden.

[Dejan Vu]

Natürlich müsste ich existierende Reports anpassen, sofern die Änderung der DB auch diese betrifft.

Aber wenn ich zu dem Faktura-Modul noch eine weitere Tabellenstruktur für Vergleichsauswertungen der zwiefach genoppten Frumvondelstatistik hinzufüge, muss ich die existierenden Reports nicht anfassen. Und mein Programm muss ich auch nicht erweitern, d.h. Datenquellen hinzufügen.

Wenn der Kunde dann seine zwiefach genippften (oder waren das doch die genoppten?) Frumvondel sehen will, schicke ich ihm eine FR3-Datei und fertig ist der Lack (oder der Drops gelutscht).

Ich will mich jetzt natürlich nicht hinstellen, und behaupten, das wäre besser. Denn es kommt natürlich immer darauf an, ob ich die Kontrolle auf die Daten abgeben will bzw. ob es überhaupt Sinn macht, die Daten der DB anzuzapfen.

Das derzeitige Projekt, welches ich betreue, verfolgt genau diesen Ansatz, d.h. die Daten liegen nur in der Applikation vor und die Reportingengine bedient sich daraus. Hat Vor- und Nachteile.