Reports allgemein Datentrennung

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

[Hansa]

Normalfall dürfte wohl folgendes sein : Ich will irgendetwas nachgucken und hole mir das auf den Bildschirm. Datenmenge ist also bereits bekannt. Wenn ich das jetzt auch noch drucken will, warum soll denn dann der Report auch noch die Datenmenge neu ermitteln ?

[Dejan Vu]

Mein Normalfall ist: Kunde hat ein Reportingmodul und will eine Auswertung haben.

[mm1256]

Mein Normalfall ist: Kunde will ein Angebot oder eine Rechnung drucken. Mit Ansehen am Bildschirm alleine wird das nix
Also vielleicht wieder zurück zum Thema "Datentrennung". Ich denke nach wie vor, je komplexer die Reports umso sinnvoller kann eine Datentrennung sein.