Post reply

Crystal Reports and Views

  • January 20, 2005 at 10:38 am

    #86600

    We have a third-party package. The vendor has been asked to create several reports, using Crystal Report, for one of our departments. Everytime a new report is requested the vendor sends the DBA team a script which creates new Views. There are one or more views created per report. That means any future version uprades needs to take into account all of the custom views. I asked the vendor why a view is needed since I thought he could query the base tables directly. This was his response.

    "Crystal can do very complex things but most of the time it requires bringing all the data into the report at run time which the report applies logic to and generally displays only a small portion of the data. Views can pair down much of the data on the database side and minimize the amount of data that has to move across the network and into the report for processing."

    "Performance

    · Reduction of data moving across the network

    · Reduction of data processing done within the report.

    · Better/faster data processing done on the database server than in a client app."

    I'm not too familiar with Crystal Reports, but I'm having a hard time understanding his logic. I thought views only increase performance if they are indexed or partioned, which in this case they are not. The underlying query that makes up the view still gets executed dynamically.

    Thanks, Dave

  • January 21, 2005 at 12:14 am

    #538445

    He is correct.

    Crystal's performance is the issue here, and it sucks. The dbms is capable of doing a lot of things many orders of magnitude faster than Crystal. There may well be performance issues related to the views themselves, but that is a seperate issue. In every case I've seen, a poorly performing view still whips the tar out of the performance you'd see having Crystal perform the same operation. I once dealt with a Crystal Report which took 2.5 hours to run. By shifting the workload over to the dbms, I got it down to 14 seconds. On the other hand, while I generally take the position that views are your friend, not all reports need views. As for version upgrades, I don't think I'd be concerned at all ( easy for me to say since I'm not actually a dba Breaking backwards compatibility on views would be a massive no-no.

    Shane

  • January 21, 2005 at 6:32 am

    #538496

    I'm on a Crystal Reporting team project at this moment (with a Sybase backend, ugh!) and we are converting every report that we can from using linked tables and views to using stored procs.  We generally see performance gains from running 2 min in dev to running in 10 -15 seconds.  Changes to the procs, just like with changes to a view, simply require a 'Verify Database' on the Crystal Report side so that the added/removed/modified fields are recognized.

    Crystal is great for handeling some of the trickier formatting issues, but let the dbms handel EVERYTHING else.

    Regards,
    Matt

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply