Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reporting issues and Peregrine SC

Status
Not open for further replies.

steever

MIS
Mar 25, 2003
43
CA
Just want to pick the collective brain here :)

Within our org here, we're running Service Center and reporting against it using Crystal. Been hitting the wall recently (I'm the reporting guy) as reporting reqs are getting far more complex, P4 being non-relational and subreports only getting me so far. I'm currenlty writing up a document for management to try and justify a merge or copy of the p4 db over to our Oracle db (or something to facillitate the reporting process?).

This would make reporting a breeze and would leverage our existing Cognos tools allowing us to get into OLAP/MOLAP, etc.

So folks, what do you see as greatest limitations to reporting in SC against the P4 db? Or what kinds of common probs do you guys find yourselves running into when reporting??

thx for any input ...

Steve
 
I wasn't able to get the sub reports working correctly (in CR v8.x) so we had to shadow the P4 DB to a SQL DB.
If you just "shadow" the p4 database to another server, the reporting DB server doesn't become a vital part of the ticket system.
I love Crystal Reports for complex reports, but we don't use it anymore, because most ppl don't understand how Crystal Reports works.
I'm using some smart sql views so that even ms office users are able to pull off some amazing reports.
With some Excel, a little VBA, SQL Views and Pivot "self service" becomes mutch easier.
In short: Trying to pull off the relational part in CR because P4 isn't able to do that, is a really bad idea.

If you need to argue, say that all reports that need sub-reports might not work correctly.

English isn't my native tongue, so sorry for my spelling :).
 
Definitely recommend pushing out at least tables you're going to be reporting on to an RDBMS. We do that, then have processes that copy that data over to another DB instance to actually report on.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top