Wozu braucht man einen Report-Generator?

[Dejan Vu]

Zitat von p80286:

Natürlich ...

Natürlich ist Word vollkommen Überflüssig. Es gibt nichts, was man mit Word machen kann, was man mit einem Stift und Papier nicht machen könnte.

Insofern sind Autos, Wohnungen, Messer, Gabel, Herde, Pfannen und BBQ-Grills (Nein! BBQ nicht! Das geht zu weit!) auch überflüssig.

In der professionellen Softwareentwicklung geht es nicht nur darum, ein Problem 'irgendwie' zu lösen, sondern darum, das Problem schnell und zuverlässig zu lösen. Beides ist mit einem (mal wieder) selbstgefrickelten -wie auch immer- Report-O-Maten nicht so hinzubekommen.

Ich z.B. bevorzuge für die Ausgabe von Tabellen den PrintManager von DevExpress, bei dem ich gar nichts mehr designen muss. Es ist quasi ein Screenshot meines Grids, nur eben auf DIN-A4 Papier gerendert, mit Seitenzahlen, Kopf/Fusszeilen etc. Da habe ich mit Leichtigkeit mal eben 30-100 Reports an einem Tag programmiert (eher: geklickt), sofern die Grids schon vorhanden sind. RAD at its best.

Ich verwende Fast-Report auch zum Ausdruck von Barcode-Etiketten. Der Anwender wählt das Format oder misst es aus, erzeugt das Design und -schwupps- hat er seine 10000 Etiketten gedruckt. Mit fortlaufender Seriennummer.

Für Rechnungen -oder allgemein- für Serienbriefe kann man natürlich Word nehmen. Oder besser noch: Open Office, weil das nix kostet. Aber hat der Kunde auf dem PC denn überhaupt ein Office installiert? Wenn ja, will er dann noch zusätzlich OO (oder eben Word)? Darf ich überhaupt auf dem PC etwas installieren? Und was ist mit den 100 anderen Anwendern? Und wenn ich OO nehme und der Kunde zufrieden ist, wie lange brauche ich, um alle tollen Features zu programmieren? FastReport kostet -keine Ahnung- 200-300 Euro. Das sind 2-6 Stunden meiner/deiner Zeit. In der Zeit habe ich gerade mal OO (oder Office, egal) downgeloaded, installiert und erste Gehversuche mit der API gemacht.

Man kauft sich also einen Reportgenerator/Framework, weil man Zeit und Geld sparen will. Wer meint, das alles selbst oder besser machen zu können, ist entweder ein Genie, kann nicht rechnen, hat zuviel Geld oder ist ein Hobbyprogrammierer. Oder er ist schlicht und ergreifend bescheuert (wie der derzeitige 'Head of Development' in der Firma, für die ich arbeite, hallo Stefan ).

Aber eins ist klar: Wenn Du so eine Frage stellst, dann hast Du bisher noch nicht die Notwendigkeit für einen Reportgenerator gehabt. Ich hatte z.B. noch die die Notwendigkeit, eine Android-App bauen zu müssen. Wozu dann also ein neues Delphi?

[baumina]

Egal ob mit oder ohne Reportgenerator, es war und ist schon immer nervig, wenn der Kunde sagt "Ich bräuchte da nochmal eine Liste mit folgenden Daten... einmal auf den Drucker und einmal als Exceltabelle... ". Warum das in der heutigen Zeit immer noch so ein Gefriemel sein muss, ist mir ehrlich gesagt auch ein Rätsel

P.S. Ich habe die letzten beiden Tagen nichts anderes gemacht als ReportBuilder-Reports auf eine neuere Version und von Zeos-Zugriff auf UniDac-Zugriff umzustellen, jeder Versuch das automatisiert zu machen scheiterte.

[Dejan Vu]

Zitat von baumina:

Warum das in der heutigen Zeit immer noch so ein Gefriemel sein muss, ist mir ehrlich gesagt auch ein Rätsel

Bei DevExpress ist das ein Aufruf ('ExportToExcel') und wie einfach Grids in Reports umzuwandeln ist, hab ich bereits erzählt. Im aktuellen FR gibt es ein Table(oder Matrix?) Konstrukt, mit dem das fast genau so schnell geht.

Gefriemel ist das, was der Vorgesetzte zulässt. Wenn man, wie bei Dir, nicht willens ist, zu rechnen, ist das ja fast so, wie bei mir: 300 Euro für ein FR-Update eingespart, aber 1000 Euronen für zusätzliche Arbeit ausgegeben.

Gut, DevExpress ist zwar teurer, aber dann geht die Rechnung (Einsparen) eben über einige Wochen und die gepimpte UI ist j auch was wert. Alleine schon das Grid... schwärm.

[baumina]

Zitat von Dejan Vu:

Wenn man, wie bei Dir, nicht willens ist, zu rechnen, ...

Welche meiner geschriebenen Aussage veranlasst dich diesen Schluss zu ziehen?

[Dejan Vu]

Zitat von baumina:

Zitat von Dejan Vu:

Wenn man, wie bei Dir, nicht willens ist, zu rechnen, ...

Welche meiner geschriebenen Aussage veranlasst dich diesen Schluss zu ziehen?

Das war wirklich dumm ausgedrückt von mir. Entschuldige.

Gemeint war: "Wenn man, wie bei deiner Firma, nicht willens ist..."

[Daniel]

Und Du kennst bauminas Reporte, Umgebung und Anforderungen derart genau, um Dir sicher sein zu können, Dir diesen flapsigen Kommentar erlauben zu können? Wozu überhaupt anderen Usern ungefragt ans Bein pinkeln? Über konstruktive Anregungen ist bestimmt jeder froh, aber sowas ... ?

In der Tat. Keine gute Idee.

[Dejan Vu]

Zitat von Daniel:

Wozu überhaupt anderen Usern ungefragt ans Bein pinkeln?

PN.

Zitat von p80286:

Soll es ein Brief werden, bevorzuge ich Word oder AdobeArcobat.

Das stimmt allerdings auch wieder und wenn der Kunde Word-95 haben will, dann muss man das auch so machen. Meine Kritik an 'Word' galt allerdings dem 'geeigneten Werkzeug als Reportgenerator', aber da das nun differenziert ist ('Serienbriefe'), kann man das auch so stehenlassen.

[p80286]

Zitat von Dejan Vu:

Zitat von p80286:

Natürlich ...

Natürlich ist Word vollkommen Überflüssig. Es gibt nichts, was man mit Word machen kann, was man mit einem Stift und Papier nicht machen könnte.

Wenn Du jetzt noch einen Scanner spendierst, um ein Word-Document zu erstellen, dann stimmt es wieder.

Es kommt immer auf die Anforderungen des Kunden an. was man für die Datenausgabe benutzt. Ich glaube nicht, das die Druckausgabe eines Gitters, die wesentlicher Aufgabe eines Reportgenerators ist. Wenn man eine tabellarische Ausgabe möchte ist ein Reportgenerator für mich erste Wahl. Soll es ein Brief werden, bevorzuge ich Word oder AdobeArcobat.

Und wenn der Kunde unbedingt eine Tabelle im Word-Format haben will dann muß man sich was einfallen lassen.

Gruß
K-H

[mkinzler]

Die Reportgeneratoren können ja auch schon PDF, Word, Excel und die entsprechenden OpenOffice Formate ausgeben.

[jobo]

was mir noch einfällt:
- dynamische Datendarstellung für "beliebig" große Datenmengen (Listen/Grids) inkl.
- Seitenumbruchkontrolle, -Erkennung
- Aggregatfunktionen
- Zwischensummen (Head / Footer)
- Abbildung von Datenrelationen
- Komplexe Formeln
- Datensensitive Diagramme
- Template-, Script-, API-Schnittstellen
-- API erlaubt interaktive Änderung der Darstellung
- embedded, clientside, serverside, filebased Templates

Word hat dagegen eine relativ kleine Teilmenge. Ausgenommen ich baue über COM alles zu Fuß, aber dann kann ich auch gleich Canvas nehmen.