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.