We are running Crystal Reports 2013 sp7 hosted on BI4.1sp7 and using SQL Server 2012 for the database. We have a number of Crystal Reports that were originally written against a stored procedure universe (UNV). Because of a bug with Business Objects that doesn’t pass date values into the stored procedure correctly, these reports have been converted over to use the stored procedures directly.
The conversion was done by using the Set Location option in Crystal Reports Developer. The same ODBC DSN was used for the stored procedure based universe and for the stored procedure access.
When I look at the properties of the Crystal Report in the Central Management Console, I still see references to the universe there.
Does anyone know why this might be?
Is there a way to remove the reference?
We have some reports that have failed with the following errors and I am trying to rule out this “ghost” reference if possible.
[list]Failed to open the connection. _tmpBlahBlahBlah.
Error in File ~tmpBlahBlahBlah.rpt:Unable to connect: incorrect log on parameters.Details: [Database Vendor Code: 18456 ]
Error in File ~tmpBlahBlahBlah.rpt:Unable to connect: incorrect log on parameters.
Error in File ~tmpBlahBlahBlah.rpt:Failed to retrieve data from the database.Details: [Database Vendor Code: 927 ][/list]Trying to sort this mess out.
Database Vendor Codes are the error code from the database which are just passed through Crystal. To get the actual information about the error, you would need to google it specifically for SQL Server.
When you use a universe in Crystal, all of the data connection info is stored in the Connection definition for the universe. When you connect directly to a database, you need to include that information in the default database configuration for the report. Here’s what you need to do after publishing the report:
Find the report in the CMC.
Right-click on it and select “Database Configuration”.
It will should the ODBC name/database alias, etc. and the user ID that the report was designed with. However, the password will be blank.
a. If this is the correct database for the environment, fill in the correct password and save.
b. If the connection needs to change, set it as a “custom” connection and enter all of the appropriate information.
If users will run reports interactively (view on demand) instead of just scheduling them, make sure that the drop-down list at the top of the screen says something like “Use the same login as when the report it run”.
We have already been through those steps and verified the access. It hasn’t solved the problems. The problem is that these errors are intermittent. I was hoping that the universe references that were left behind could be removed to remove that as a potential issue.
When I googled the db error codes, I found that SQL Server error 927 means that the database is being restored. While it’s being restored, you can’t access the data.
So, this has nothing to do with the report itself, it’s an issue in the database.
This is what I thought even though the report developers swear that they have a dependency in place in our scheduling tool to not run the reports until after the restore completes. I just haven’t gotten to look up that error yet. I’m finding some dependencies on some other data sources that make it more complicated also as I look at the reports.
The universe still showing as being related to the report is just one track I’m investigation and didn’t have any other resources for that one.
The only other option would be to recreate the report from scratch using the stored proc and then saving it over the top of the existing report. This is not as hard as it sounds because you can copy objects and formulas from the old one to the new one. The only things you have to manually do are connect to the stored proc, set up the groups, handle any section or object suppression, and handle any other section formatting.
(BOB member since 2007-04-16)