What's so bad about Crystal Reports?



  • I haven't seen Crystal Reports mentioned nearly as often 'round these parts as several other things, but when it is, it's pretty much always in a negative context. Just a day or two ago, someone flat-out said "okay, so pretty much all of us hate Crystal and Oracle". This strikes me as odd, because over the past few years, I've (used / seen it used) more and more in the packages that I do custom work on, and been glad every time. If there's one occasion on which drag-and-drop and functional programming are obviously the Right Thing To Do, it's report design: vastly superior to pages and pages of tedious procedural code. I mean, would you rather work with this (procedural pseudocode):

    1000 READ NEXT INVOICE HEADER RECORD (ON EOF GOTO 5000)
    1010 IF CUSTOMER <> LAST CUSTOMER THEN GOSUB 3000
    1020 LAST CUSTOMER = CUSTOMER
    1030 GOSUB 1500; REM READ OTHER RECORDS RELATED TO HEADER
    1040 GOSUB 2000
    1050 IF NOT DISPLAY DETAIL THEN GOTO 1200
    1060 POSITION POINTER FOR THIS HEADER RECORD'S DETAIL RECORDS
    1100 READ NEXT INVOICE HEADER RECORD (ON EOF GOTO 1200)
    1110 GOSUB 1600; REM READ OTHER RECORDS RELATED TO DETAIL
    1120 GOSUB 25001130 GOTO 1100
    1200 T = T + INVOICE'S CURRENT BALANCE
    1210 GOTO 1000
    2000 PRINT (COL 1) INVOICE NUMBER,
    2010 PRINT (COL 15) INVOICE DATE
    2020 PRINT (COL 30) DUE DATE
    2030 PRINT (COL 45) ORIGINAL BALANCE
    2040 PRINT (COL 60) CURRENT BALANCE
    2050 RETURN2500 PRINT (COL 10) ITEM NUMBER
    2510 PRINT (COL 30) QUANTITY
    2520 PRINT (COL 40) UNIT PRICE
    2530 PRINT (COL 50) TOTAL PRICE
    2540 RETURN
    3000 PRINT
    3010 PRINT (COL 65) "----------"
    3020 PRINT (COL 65) T
    3030 GOSUB 6900; REM FORM FEED
    3040 IF NOT END OF REPORT THEN GOSUB 3500
    3050 RETURN
    3500 PRINT (COL 1) CUSTOMER NUMBER, (COL 15) CUSTOMER NAME
    3510 PRINT
    3520 RETURN
    or this (Crystal pseudolayout)?
    [Group 1 Header]
      [Customer Number] [Customer Name]
    [Group 2 Header]
      [Invoice Number] [Invoice Date] [Due Date] [Original Balance] [Current Balance]
    [Detail - suppress if not(@Display Detail)]
      [Item Number] [Quantity] [Unit Price] [Total Price]
    [Group 2 Footer]
      ----------
      [Running Total of Current Balance,
     updated on change of G2, cleared on change of G1]
    [Group 1 Footer]
      ...

    Okay, sometimes part of the logic is complex enough that a procedural approach works better, but then you just run that logic from the front end before Crystal is invoked.

    I know Crystal has various problems (older versions felt clunky - I've been working with 8.5 for a while because the aforementioned packages have some specialized tie-ins to that version), but they're so uncommon and/or easy to work around that I, at least, barely think about them. What problems do you see with Crystal that make it really irritating to work with?



  • One of the things that I found that really bothered me in CR 10 was that I could crash the report making tool with one 'missclick'.

    For the rest it may have been the fact that our clients are really really touchy on how their reports print, so that our report maker has to fiddle immensly with how a report looks. He doesn't seem to have any problems with the logic though.

    Drak



  • @Drak said:

    One of the things that I found that really
    bothered me in CR 10 was that I could crash the report making tool with
    one 'missclick'.



    I've run across that, but only rarely.  Perhaps CR 10 is worse about it.

    @Drak said:

    For the rest it may have been the fact that our clients are really really touchy on how their reports print, so that our report maker has to fiddle immensly with how a report looks. He doesn't seem to have any problems with the logic though.



    Clients like that will eat up lots of your time no matter what tool you use, and (once again) making cosmetic changes in CR is much easier and less prone to accidental omissions than making the same cosmetic changes in pure procedural code.



  • I didn't actually use CR10 very much, as I got it to crash 3 times before even starting on a report. I then gave up (I didn't need to use it at that time, and will never have to use it now).

    One the second comment, yup you're right. Clients like that will eat up much time, and I'm willing to believe you that CR is then easier for layout than code.

    Drak



  • SQL Reporting Services.



    Nuff Said.



    (If you're running SQL Server, anyways).






  • <FONT style="BACKGROUND-COLOR: #efefef">Yeah, I'm being forced to use it now. Its like Sisiphus (sp?).. One step forward... *crash*... one step back. Well. Its either this or "use xml!". Great, that will really solve our problems. Like javascript.. which I havent tried yet ;)</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef">I'm writing this after calling my contract manager and telling him that I expect my next contract to have a different organisation on it ;)</FONT>



  • <javascriptAdvocacy mode="on">There are some very powerful things you can do in javascript to enhance your reports on-screen</javascriptAdvocacy>

    I have a nice vertical line following the mouse and listing X,Y values on my graphs. People (read managers) seem to like that a lot [:D]

    Drak



  • @Blue said:

    SQL Reporting Services.



    Nuff Said.



    (If you're running SQL Server, anyways).








    Which, with one exception, I'm not.  Another advantage of CR--
    learn just one tool that hooks up to any damn ODBC source you care to
    throw at it.



    The consensus answer to my original question seems to be "they fucked
    up stability somewhere between 8.5 and 10". Thank you, that's very
    useful to know about.




  • Having just spent two days trying to get Crystal Reports to work under NT4 (large bank, don't ask) and finding out random requirements not mentioned anywhere, including DLLs which I've had to hunt around ms.com for, and merge modules which I had to get from installshield.com I can safely say CRYSTAL REPORTS SUCKS DOG'S DONGS.



  • @emurphy said:

    The consensus answer to my original question seems to be "they fucked up stability somewhere between 8.5 and 10". Thank you, that's very useful to know about.

    Glad to be of help [:D]

    Drak



  • My top 5 reasons for HATEING Crystal Reports (6-10).

    5. CRPE ERROR: NO ERROR

    4. Prints to select printers (prints blank pages or errors to others)

    3. Prints to a printer from this computer, but will not print to it from that computer.

    2 Exporting does not create documents suitable to send to anyone with out some manual labor. (I have not tried version 10 on this one yet.  8.5 still could not produce a good word document with correct headers and footers.)

    1 CRPE ERROR: NO ERROR

     

    Note: none of these have anything to do with how hard/easy it is to use when creating a report.  For my experience, html/java has been MUCH more reliable when in use.



  • @blowdart said:


    Having just spent two days trying to get Crystal Reports to work under
    NT4 (large bank, don't ask) and finding out random requirements not
    mentioned anywhere, including DLLs which I've had to hunt around ms.com
    for, and merge modules which I had to get from installshield.com I can
    safely say CRYSTAL REPORTS SUCKS DOG'S DONGS.





    Hrm, certainly haven't encountered anything like that before. I did
    have a client a few years ago that mostly used NT4, but CR wasn't even
    part of my toolset yet.



    This may have to do with the accounting app that front-ends CR for most
    of our clients. First, it displays the reports in a special
    view-or-export-only window, so that end users don't need CR itself
    installed; CR itself is generally only installed on reasonably
    up-to-date development boxes. Second, the accounting app itself
    requires a reasonably up-to-date box, anyhow. (The latest series
    requires Win2K or later. Not too shabby, considering the very first
    Windows series - dating back to 1997, with about one major release per
    year - still runs on Win2K or earlier. One of our clients finally
    decided to upgrade from that first series because dammit, they wanted
    to use XP; after months of effort to migrate their heavy
    customizations, we're finally pulling the switch tonight.)


    @codewulf said:

    5. CRPE ERROR: NO ERROR


    Have encountered this rarely, if ever. Launching reports through the limited interface (see above) tends to be cryptic about any errors that come up, but 99% of the time, running the same report through the designer clears things up pretty quickly.

    @codewulf said:


    4. Prints to select printers (prints blank pages or errors to others)
    3. Prints to a printer from this computer, but will not print to it from that computer.


    Have encountered these rarely, if ever.

    @codewulf said:


    2 Exporting does not create documents suitable to send to anyone with out some manual labor. (I have not tried version 10 on this one yet.  8.5 still could not produce a good word document with correct headers and footers.)


    Have been asked to do this rarely, if ever. Exporting to Excel (so the end users can run the numbers through additional formulas) is much more common. If we want a human-readable document, we use PDF.

    @codewulf said:

    Note: none of these have anything to do with how hard/easy it is to use when creating a report.  For my experience, html/java has been MUCH more reliable when in use.



    I suppose it'd be a viable option if I had, y'know, a few years experience rolling out Java apps.



  • @blowdart said:

    .. I can safely say CRYSTAL REPORTS SUCKS DOG'S DONGS.

    +5 Informative

    I'm not arguing here. My IDE has crashed 18 times today.


Log in to reply