FastReport vs Crystal Report

[Cogito]

Hallo zusammen,

ich bin noch am evaluieren dieser beiden Produkte, tendiere aber sehr stark zu FastReport, weil ich deren Script-Engine als sehr gut empfinde. Dadurch wird es möglich komplexe Aufgaben in einem Report zu erledigen. Allerdings muss ich gestehen dass ich Crystal Reports einmal in der Version 7 genutzt habe und seither nicht mehr. Aber ich habe es damals irgendwie als mehr Entwickler-lastig gesehen, also als umfangreiches Produkt für Programmierer und weniger als Enduser. Kennt jemand von euch diese beiden Produkte und kann mir hier mehr Material liefern?

Vielen Dank im Voraus.

[MaBuSE]

Zitat:

Zitat von Cogito

Hallo zusammen,
ich bin noch am evaluieren dieser beiden Produkte

Vergiss CrystalReports.

Es gibt offiziell keinen Delphi Support mehr.

Die TCRPE-Komponente ist für Delphi 7 und CR v8 bzw. v9

Wenn Du v10 verwenden möchtest, musst Du den Quelltext der Komponenten an einigen Stellen patchen.

Die Komponenten setzen auf eine alte CR Schnittstelle auf, die nur noch der Kompatibilität wegen mitgeliefert wird. (Wie lange noch?)

In Delphi 2007 funktioniert nach den Anpassungen noch alles, aber mit Delphi 2010 -> Unicode gibt es Probleme. Die alte Komponente ist nicht dafür ausgelegt.

CR wurde von SAP gekauft.
Ich habe in einem SAP Supportformum gelesen, das der Einzige, der sich mit Delphi gut auskannte und damals die TCRPE-Komponente schrieb, die Firma verlassen hat. Die geben keinen Delphi Support, weil sie keine Ahnung von Delphi haben.

Das offizielle Statement von SAP zu CR und Delphi ist, auf DotNet umzusteigen. :-(

Das ist für und keine Option.
Aus diesem Grund schauen wir auch nach einer anderen Lösung.

Ich werde mit demnächst auch Fast Report anschauen, der ist für Delphi (auch Delphi 2010 mit Unicode) und DotNet verfügbar.

Ich hoffe diese Infos helfen Dir.
MaBuSE

[Cogito]

JA vielen Dank, das war auch so mein Gefühl bei Crystal Reports.
Gibt es denn aus Sicht des Endanwenders irgendwas zu den beiden zu sagen? Ich denke Crystal Reports gibt es ja schon so lange, das Ding muss doch einfach alles können, oder?

[mkinzler]

FR kann auch viel. es ist immer die Frage was benötigt wird.

[hoika]

Hallo,

also ich hatte mit CR8.5 Probleme mit "supressed"-Dingern,
also z.B. Band nur auf 2. Seite anzeigen.
Damit gab es "Lücken" beim Drucken.

Da ich meine Daten gerne selbst übergebe, bin ich an die Grenze von 255 Zeichen gekommen (per Blob wäre es gegangen).

Das ganze OLE-Zeug hat mich wahnsinnig gemacht ;)

Wenn es Löhnware ein soll und es etwas kosten kann,
würde ich Crystal Reports nehmen.


Heiko

[Cogito]

Besonders gut finde ich das Scripting in FastReport. Damit lässt sich ganz schön was anfangen. Hat CR sowas auch?

[MaBuSE]

Zitat:

Zitat von hoika

also ich hatte mit CR8.5 Probleme mit "supressed"-Dingern,
also z.B. Band nur auf 2. Seite anzeigen.
Damit gab es "Lücken" beim Drucken.
...
Wenn es Löhnware ein soll und es etwas kosten kann,
würde ich Crystal Reports nehmen.

Verstehe ich das richtig?
CR macht bei Dir Probleme, aber Du wurdest CR empfehlen?
Auch, wenn es mit keiner habwegs aktuellen Delphi Version läuft.

[mkinzler]

Manche stehen halt auf Probleme :mrgreen:

[MaBuSE]

Zitat:

Zitat von mkinzler

Manche stehen halt auf Probleme :mrgreen:

Ach so, na dann. Viel Spaß mit CR :mrgreen:

[Thomas Feichtner]

Hallo,

hast du dir schon mal RBuilder angesehen?

[DSCHUCH]

Hallo, ich habe vor einigen Jahren auch diverse Möglichkeiten evaluiert. Die beste Lösung erschien uns damals FR. Gründe:

Klein, einfach, sehr umfangreich, extrem flexibel, Delphi-Nativ, Quellcode.

Wir sind bis jetzt sehr sehr zufrieden damit.

Daniel.

[mkinzler]

Ich habe mich nach einem Vergleich zwischen ReportBuilder und FastReport auch für FR entschieden. Früher habe ich QR benutzt; Rave fand ich aber irgendwie nicht so toll.

[Sir Rufo]

FastReport ist schon sehr cool hat aber auch seine Schwachstellen:
(Version 4.9 VCL)

- PDF-Export schreibt grausliche PDF-Dateien
als Folge davon werden z.B. auf dem iPhone/Mac keine Schriften mit dem Attribut Fett angezeigt
Quark XPress stürzt beim einlesen einer PDF ab
RichText-Felder werden als Bitmaps exportiert

Eine Ausgabe des Reports über einen PDF-Printer (pdfFactory) ergibt eine perfekte PDF-Datei

- Datenverbindungen aktualisieren sich nicht
Im Report erstellte Abfragen können zwar verbunden werden, jedoch wird die verbundene Abfrage nicht aktualisiert

Die Script-Engine ist sehr genial, vor allem weil sich diese recht einfach erweitern lässt.
Die fehlende MySQL-Unterstützung kann man so mal eben mit unterjubeln.

[mkinzler]

FastReport liefert für allen möglichen Zugriffskomponenten ( z.B. von DevArt) spezielle DataSets, sicherlich auch für MyDAC

[Sir Rufo]

Zitat:

Zitat von mkinzler

FastReport liefert für allen möglichen Zugriffskomponenten ( z.B. von DevArt) spezielle DataSets, sicherlich auch für MyDAC

Wo ... hab ich da noch nicht gesehen. Darum habe ich ja die MyDAC dort eben eingebunden (10 Minuten Aufwand)

[Memo]

Zitat:

Zitat von Sir Rufo

Die fehlende MySQL-Unterstützung kann man so mal eben mit unterjubeln.

Wo wird das nicht unterstützt? Das frDBDataset kann alle möglichen DB-Kompos angebunden werden.

[Cogito]

Zitat:

Zitat von Sir Rufo

FastReport ist schon sehr cool hat aber auch seine Schwachstellen:
(Version 4.9 VCL)

- PDF-Export schreibt grausliche PDF-Dateien
als Folge davon werden z.B. auf dem iPhone/Mac keine Schriften mit dem Attribut Fett angezeigt
Quark XPress stürzt beim einlesen einer PDF ab
RichText-Felder werden als Bitmaps exportiert

Eine Ausgabe des Reports über einen PDF-Printer (pdfFactory) ergibt eine perfekte PDF-Datei

- Datenverbindungen aktualisieren sich nicht
Im Report erstellte Abfragen können zwar verbunden werden, jedoch wird die verbundene Abfrage nicht aktualisiert

Die Script-Engine ist sehr genial, vor allem weil sich diese recht einfach erweitern lässt.
Die fehlende MySQL-Unterstützung kann man so mal eben mit unterjubeln.

Wie lässt sich denn die Script-Engine erweitern und wie arbeitet man dort mit der Datenbank? Kannst Du mal Beispiele geben?

[Cogito]

Könnt ihr mir noch ein paar Tips geben für die Benutzer, welche bisher gewohnt waren mit Crystal Report zu arbeiten, was mit FR jetzt besser ist? Ich meine, so ein Argument wie "...es gibt keine vernünftige Delphi Komponente für CR..." kratzt die herzlich wenig...
Es geht bei mir auch darum dass ein Benutzer die Reports anpassen kann und wenn er jetzt plötzlich statt vorher 150 Funktionen jetzt nur noch die Hälfte hätte, würde sich vermutlich schnell Unmut breit machen.

[Sir Rufo]

Zitat:

Zitat von Memo

Zitat:

Zitat von Sir Rufo

Die fehlende MySQL-Unterstützung kann man so mal eben mit unterjubeln.

Wo wird das nicht unterstützt? Das frDBDataset kann alle möglichen DB-Kompos angebunden werden.

Das ist schon richtig, in meiner Anwendung machen ich den Zugriff auf die DB und übergebe das DataSet dann an FR.
Aber das meinte ich nicht.

Beim FastReport kann ich direkt im Report auch einen Zugriff auf die Datenbanken machen.
Mittels ODBC könnte ich (wenn der MySQL-ODBC installiert wäre) auch auf MySQL zugreifen.
Aber ich finde MyDAC halt schöner ;)

Mit dieser Unit wird dann auch MyDAC direkt im Report benutzbar.
Einfach da einbinden, wo auch die FR-Komponente liegt.

Delphi-Quellcode:

{******************************************}
{                                          }
{             FastScript v1.9              }
{       MyDAC classes and functions        }
{                                          }
{******************************************}

unit fs_imysrtti;

interface

{$I fs.inc}

uses
  SysUtils, Classes, fs_iinterpreter, fs_itools, fs_idbrtti, db, DBAccess,
  MyAccess, DAScript, MyScript, MemDS;

type
  TfsMYSRTTI = class( TComponent ); // fake component

implementation

type
  TFunctions = class( TfsRTTIModule )
  private
    function CallMethod( Instance : TObject; ClassType : TClass;
      const MethodName : String; Caller : TfsMethodHelper ) : Variant;

  public
    constructor Create( AScript : TfsScript ); override;
  end;

  { TFunctions }

constructor TFunctions.Create( AScript : TfsScript );
  begin
    inherited Create( AScript );
    with AScript do
      begin
        with AddClass( TDAParam, 'TParam' ) do
        begin

        end;
        with AddClass( TDAParams, 'TParams' ) do
        begin

        end;

        with AddClass( TCustomDAConnection, 'TCustomConnection' ) do
          begin
          end;

        with AddClass( TCustomMyConnection, 'TCustomDAConnection' ) do
          begin
          end;

        with AddClass( TMyConnection, 'TCustomMyConnection' ) do
          begin
          end;

         with AddClass( TMemDataSet, 'TDataSet' ) do
           begin
           end;

         with AddClass( TCustomDADataSet, 'TMemDataSet' ) do
           begin
             AddMethod( 'procedure Execute', CallMethod );
             AddMethod( 'function Executing : boolean', CallMethod );
           end;

        with AddClass( TCustomMyDataSet, 'TCustomDADataSet' ) do
          begin
          end;

        with AddClass( TMyTable, 'TCustomMyDataSet' ) do
          begin
          end;

        with AddClass( TMyQuery, 'TCustomMyDataSet' ) do
          begin
          end;

        with AddClass( TDAScript, 'TComponent' ) do
        begin

        end;
        with AddClass( TMyScript, 'TDAScript' ) do
        begin

        end;

      end;
  end;

function TFunctions.CallMethod( Instance : TObject; ClassType : TClass;
  const MethodName : String; Caller : TfsMethodHelper ) : Variant;
  begin
    Result := 0;

    if ClassType = TCustomDADataSet then
      begin
        if MethodName = 'EXECUTE' then
          TCustomDADataSet( Instance ).Execute;
        if MethodName = 'EXECUTING' then
          RESULT := TCustomDADataSet( Instance ).Executing;
      end;

  end;

initialization

fsRTTIModules.Add( TFunctions );

finalization

if fsRTTIModules <> nil then
  fsRTTIModules.Remove( TFunctions );

end.

Zitat:

Zitat von Cogito

Könnt ihr mir noch ein paar Tips geben für die Benutzer, welche bisher gewohnt waren mit Crystal Report zu arbeiten, was mit FR jetzt besser ist? Ich meine, so ein Argument wie "...es gibt keine vernünftige Delphi Komponente für CR..." kratzt die herzlich wenig...
Es geht bei mir auch darum dass ein Benutzer die Reports anpassen kann und wenn er jetzt plötzlich statt vorher 150 Funktionen jetzt nur noch die Hälfte hätte, würde sich vermutlich schnell Unmut breit machen.

Welche Funktionen möchtest du denn haben?

Wenn es um spezielle Funktionen zum Berechnen geht, so kannst du diese genauso integrieren, wie den Zugriff auf MyDAC.

[Cogito]

Es geht um keine speziellen Funktionen die noch zu integrieren wären, sondern darum, dass viele Kunden bisher mit Crystal Report gearbeitet haben. Wenn die nun plötzlich eine Anwendung haben die weit weniger kann brauche ich auf der anderen Seite Argumente was jetzt dafür besser geworden ist.

[mkinzler]

Welche Features wären das den?

[Cogito]

Zitat:

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 :mrgreen: ) 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. :shock: Hier wird man kaum FR einführen können.

Zum Schluss noch mein Eindruck von CR:

:wall: :kotz: