Skip to Content

SAP Crystal Solutions 2011 Portfolio Update #1

SAP Crystal Reports 2011 and Developers – Update #3

 

Over the years, we’ve heard about the requirement to protect report designs, and have taken a few, mostly unsuccessful attempts at addressing this.

In SAP Crystal Reports 2011, we’ve delivered a much more effective solution to this problem.  This is what the new export to RPTR feature is for.

RPTR is a read-only RPT file. It cannot be opened by any report design tool, but it can be opened and executed by most of our viewers.

The objective of this feature is to create a mechanism for partners and developers to share their reports, while preventing downstream users from modifying them. Here’s a couple of examples:

1) A reseller wants to promote their report design skills without giving away some of their design techniques, so they export their report to RPTR with saved data to demonstrate to their prospects with SAP Crystal Reports Viewer 2011.

2) An ISV includes with their application some reports, but they don’t want end users to modify them for support reasons. So the ISV exports the reports to RPTR and they’re viewed with the .NET 4.0 report viewers (Webform, Winform, and WPF alls upport RPTR).

Viewers That Support RPTR Files

These viewers can open and execute RPTR files:

  • SAP Crystal Reports Viewer 2011
  • Viewers included with the SAP BusinessObjects BI 4.0 Platform (including SAP BusinessObjects Edge BI and SAP Crystal Server)
  • All viewers included with SAP Crystal Reports for Visual Studio 2010, including the Winform, Webform, and new WPF viewer.

Data Source Considerations for RPTR Files

While all data sources are supported with RPTR files, there are some special considerations around datasource set location.

Set location is disabled for RPTR files. If you need to modify the datasource location at runtime, we suggest the following techniques:

  1. Use ODBC or OLEDB data connection, and ensure the DSN used is exactly the same as the one used at design time.
  2. Use an ADO.NET data connection, and push the data into the report.

Other Considerations for RPTR

  • Manually renaming the RPTR file to a RPT file won’t make it readable.
  • There is no way to convert a RPTR file back to a RPT file. It’s a one-way trip.
  • Data refresh, printing, exporting, prompting all behave the same way as an RPT file.
  • In the viewers, you cannot export to RPT if you’re viewing a RPTR file.

That’s a quick summary of the RPTR feature – give it a try and let us know what you think!

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Rod Weir
    Pity about the datasource considerations.  Keeping the DSN the same is not viable in just about every situation I can think of…

    ..and pushing data means a complete re-write of the code and every report.

    Being able to update the datasource is such a handy thing to do.  It doesn’t destroy the concept of read-only reports either. 

    Here’s hoping an update will relax this restriction.

    Rod

    (0) 
    1. Blair Wheadon Post author
      Thanks for the comment Rod.  I expect that restriction will be relaxed in the future as well.  Maybe the full designer could open an RPTR file and only set datasource on it – nothing else.
      (0) 
        1. Community User
          Hi Blair,

          We are upgrading from Crystal report 8.5 to Crystal report 2011(SAP Crystal Reports(version for Visual Studio 2010). We have observed one critical issue in crystal report 2011. In CR8.5,we have used “PESetNthTableLogonInfo” (after PELogOnServer got deprecated) function for connection pooling. We can not implement connection pooling in CR2001. Does CR2011 support connection pooling? We tried to use  PUSH method but it supports upto 5K data.Our report has large amount of data so we can not use PUSH method. Is there any other alternative for this ?

          (0) 

Leave a Reply