Database SP cache invalidated on Change Data Source

.rpt Inspector Online Broker Version:


Please tell us about your environment where the Broker is running:

  • Operating System:
    Windows [7|8|8.1|10]
    WIndows 7 Pro

  • Is this running in a virtual machine:

    • If answered yes above, which virtual machine environment and version:

esx 6.0

Please tell us about your environment where the Web Browser is running:

  • Operating System:
    windows 7 pro

  • Browser kind and version:
    Chrome 67

  • Crystal Reports version:
    Crystal Reports [2016 / 14.2.x|2013 / 14.1.x|2011 / 14.0.x|2008 / 12.x.x|XI R2 / 11.5.x|XI / 11.x.x|10.x.x|9.x.x|8.5.x]

Crystal XIR2

Current behavior:

After remaping the ODBC Data Sources, reports may not run in Crystal Enterprise and Crystal Developer Database - Verify Database reports the Database procedure has change. Proceeding to fix up report!

Even though it hasn’t because I can remap an ODBC to itself and it still invalidated the reports SP cache.

Expected behavior:

The reports SP cache should not be invalidated as this causes errors when moving to a new environment and has caused a production deployment failure.

Can you provide details on the source database and destination database:

  • Kind (i.e. SQL Server, Oracle, MySQL, etc.)
  • Version (i.e. 2016)

Also, if you can take a screenshot of the ODBC driver details so we can try using same.

What are you referring to as SP cache here?

1 Like

@petergruenbeck if this is still an issue for you, please let us know with the additional information requested.

1 Like


This problems tends to manifest in a subreport that calls 2 stored procedures. After remapping the ODBC connection from one environment to another, if you just deploy it, that subreport will report a database error. Running the Verify Database on that subreport, gives a message about the database info having changes (it hasn’t because I can just remap a connection back to itself), and that the SP info was ‘Fixed Up’.

I didn’t notice the problem in the March release cycle, but it bit us in a June production release.

Is your issue confined to sub-reports with stored procedures. Have you tried reports that contain a sub-report that’s not using stored procedures? Is the same issue happening?

Its seems to consistently manifest in a subreport of a master report where the subreport calls 2 stored procedures.

Finally got some time to make a simple example stripped of customer proprietary stuff and just 38K each (vs 5MB for the production report). A master reports with 2 sub reports. 1 subreport has 1 SP call only - work ok, 2nd subreport has 2 SP call and is broken after changing ODBC mappings. Where can I upload or email these?

@petergruenbeck please use details sent in PM to send us your examples.

Received the files and have reviewed. They both appear to have same information in the database on first glance. Can you point me to what you’re expecting to see in the “broke” version when looking at the database info that’s not happening?

If you just deploy or preview the ‘broke’ version which only had the ODBC remapped the report won’t run the database SP.

In Developer, run a Verify Database and it reports that the database has changed and fixed up. Then it works.

It could just be a version number or timestamp. The sample files are otherwise identical.

Thanks for the additional details. Please try out the special build just sent you and let us know if that resolves it.

@petergruenbeck checking in to see your results with the special build we sent you a couple days ago?

Sorry I missed the download time window for the special version. Please resend it.

We’ve just released an update that adds OLE DB and change database functionality and in the process incorporated additional changes to the ODBC side (convert driver and verify database).

As announced here: Crystal Reports Change Data Source via OLE DB tool now available. Also now a Crystal Reports Change Database tool for ODBC and OLE DB.

Hopeful the changes under the hood will also resolve this issue for you. Please give the new broker a try.

As we’ve not heard back from you on this issue in the past month, assuming that it’s no longer an issue and closing this thread. Please create a new topic if this is still an issue for you.