FastReport vs Crystal Report

[mkinzler]

Welche Features wären das den?

[Cogito]

Zitat von mkinzler:

Welche Features wären das den?

DAS genau ist ja meine Frage, ich kenne Crystal Report zu wenig um bei einem Vergleich mit FR zu bestehen. Ich denke mir halt nur Crystal Report ist der Platzhirsch den es schon seit Jahren gibt und da saßen hunderte von Entwicklern seit Jahren dran. Das muss doch dann eigentlich ein sehr ausgereiftes Produkt sein und gegen das platziere ich nun ein anderes Tool, da sollte ich schon ein paar Argumente haben wenn Kunden plötzlich (eventuell nicht alle aber doch bestimmt einige) ein anderes Produkt bedienen müssen. Wir stossen mit unserem Produkt sicher in Bereiche vor, in denen bisher stark Crystal Reports (natürlich mit Anpassungen) eingesetzt wurde. Es geht hier um den Enduser der fertige Reports bearbeitet oder auch neue erstellen kann und das haben in dem Segment unserer Software viele bisher mit Crystal Reports als Enduser-Tool getan.
Ein super Feature von FR finde ich das Scripting, weil es dadurch möglich wird wirklich komplexe Reports zu entwickeln die auch eine gewisse Dynamik abdecken (z.B. Reports die zusätzlich Zugriffe aus der DB benötigen oder größenabhängige Anpassungen zur Laufzeit vornehmen). Das wäre z.B. eventuell ein Argument für einen Wechsel.

[Domo Sokrat]

Hi Cogito,

erstmal muss ich sagen: hab' keine Angst vor FastReport (FR)! Diese Engine kann sich meiner Meinung nach absolut mit Crystal Reports (CR) messen. Schau Dir mal die Erfahrungsberichte auf der FR-Seite an: http://ns.fast-report.com/en/respons...treport-4.html) Ich arbeite schon seit einigen Jahren mit Crystal. Anfänglich hatte ich mit CR nur als "Report-Schreiber" und dann in Erweiterung auch programmierender Weise (Steuerung von Reports über die RDC-Schnittstelle) damit zu tun.

Im Großen und Ganzen muss man sagen, dass FR auch (fast) all das kann, was CR kann. Nur eben auf die FastReport-Art! So können in beiden Engines z. B. Funktionen definiert werden und diese auch in den Reports angewendet werden. Bei FR erfolgt das im Scripting-Teil des Report. Bei CR ist jede Funktion an sich ein kleines separates Script. Beide Report-Designer verfügen über die Möglichkeit, einen Query-Builder zu nutzen. Bei CR ist dieser - so weit ich das sagen kann - der Einzige Weg, eine Query im Report-Designer). Bei FR kannst Du im Report (ich glaube, es wurde hier auch schon angesprochen) neben dem Query-Builder auch noch eine separate Datenmodell-Seite öffnen und Dein Abfrage-Gerüst definieren (so ähnlich wie in einem Delphi DataModule). Beide Engines arbeiten Band orientiert. Ich glaube, das hat sich bei den Report-Engines so weit überall durchgesetzt, weil's eben der beste Weg ist. Auch die Behandlung von Report-Parametern wird in beiden anders gehandhabt: In FR können entweder Dialoge in Art einer Windows-Form erstellt werden oder man erledigt das von Außen aus der aufrufenden Applikation über die Beschickung von im Report frei definierbaren Variablen. Was FR nicht sooo gut kann wie CR, ist das Defineren von Filtern und der Sortierung von Datenmengen im Report. Für mich stellt das aber an sich kein großes Problem dar, weil ich Reports in meinen bisherigen Projekten generell vor der Definition oder später dann vor der Ausführung des definierten Reports an ein DataSet binde, welches die Daten schon genau so aufbereitet zur Verfügung stellt, wie sie im Report benötigt werden.

Was FR leider im Gegensatz zu CR nicht kann, ist skalierbare Grafiken (z.B. Charts im EMF-Format) in einem PDF einzubinden. Wer also so etwas in seinen Reports dringend benötigt, sucht hier vergebens. Die einzige Möglichkeit hier in FR eine quasi-Skalierbarkeit hinzubekommen, ist die PDFs "printer optimized" zu generieren - also als Workaround.

Mit FR hast Du auch die Möglichkeit, Deine Benutzer mit einem vollwertigen Designer auszustatten, den Du "einfach so" in Deine Applikation integrierst und quasi "at a click of a button" aufrufen kannst. Diese Möglichkeit hast Du schon in der Basis-Version von FR. Ich glaube bei CR ist es so, dass jeder Anwender, der selbst Reports erstellen möchte, eine separate CR-Lizenz benötigt. So habe ich es zumindest kennen gelernt.

Was zudem zuvor schon zur Sprache kam, ist folgendes: Der Delphi-Support für CR ist (vor allem für die neue Generation der IDEs) im Prinzip nicht mehr gegeben. Die haben ja schon seit geraumer Zeit offiziell mit dotNET und dem Visual Studio angebandelt. Das ist für mich schon ein K.O. Kriterium gegen CR. FR hingegen wird weiter gepflegt und steht sogar schon kurz nach Veröffentlichung für Delphi 2010 bereit.

Weiterhin wäre es tatsächlich der Kostenfaktor. Ich kenne zwar die Preise von CR nicht, bin aber überzeugt, dass das Ganze nicht sehr günstig werden würde. Die Pro-Lizenz von FastReport 4.9 (mit Quellcode) kostet auch im Vergleich zu anderen (nicht-CR-)Report-Engines "'nen Appel und 'n Ei" und Du hast Lifetime-Support und -Updates. Der Support im FR-Forum ist auch klasse!

So, das soll aber jetzt erst mal reichen. Ich hoffe, dass ich einige Impulse in die richtige Richtung geben konnte und dass das Ganze nicht als Werbeschrift für FR aufgefasst wird ... aber auch in diesem Falle: Ich muss zwar mit CR irgendwie auskommen, FR ist aber imho für Delphi die bessere/richtige Wahl.

[juergen]

Hallo,

List & Label möchte ich hier noch in die Auswahl werfen. List & Label
Leider kann ich selbst nichts dazu sagen, da wir auch CR nutzen.
Einige unserer Kunden die zuvor CR hatten haben aber zur vollsten Zufriedenheit auf List & Label migriert (wie mir versichert wurde).

[alzaimar]

Vielleicht sollte man noch darauf aufmerksam machen, das CR eher darauf ausgerichtet ist, eigene Reports erstellen zu können, wohingegen FR ein Framework ist, mit dem man durchaus eine CR-ähnliche Funktionalität implementieren kann.

Sollen fertige Reports geliefert werden, würde ich in jedem Fall zu FR tendieren, denn der Designer ist einfach um Klassen besser, allerdings eher skriptlastig, d.h. man kann (bzw. darf ) die ganzen perversen Spezialfeatures (aka Kundenwünsche) im Skript implementieren. Da der Skriptdebugger nicht ausgereift ist und nur Basisfunktionalität implementiert, bedarf es schon einer gehörigen Portion Selbstkasteibereitschaft (die uns Entwicklern nun mal Eigen ist), um mit dem FR-Skript komplexe Reports zu erstellen.

Bei CR dagegen kann man alles in irgendwelchen Optionsdialogen einstellen. Für uns grauenhaft, aber für einen Enduser, der nicht programmieren will bzw. kann, offenbar genau das Richtige. Einer unserer Kunden verwendet CR schon immer und dort wurden die Sekretärinnen dazu verdonnert, Reports zu erstellen. Hier wird man kaum FR einführen können.

Zum Schluss noch mein Eindruck von CR: