QUESTION: My Crystal report won't run. What's the problem?
ANSWER: There are a number of possible reasons:
1) Does it work in Crystal Reports? This is always the starting point. If your answer is "I don't have Crystal Reports" or "I don't know Crystal Reports" there's not a lot we can do to help. You (or a resource at your company) MUST have a basic understanding of Crystal Reports. The bottom line is this... if someone knows Crystal Reports, all of the technical setup of our software will make sense.
Also, even if Crystal Reports is on the same machine as our software, some of the remaining items need to be checked out. Crystal Reports and the Crystal runtime engine (that our software uses) is NOT the same. Crystal Reports fixes a lot of stuff on-the-fly that it does not make available to the Crystal runtime engine.
2) Did you enter the ID/password for the report?
3) The report uses two or more DIFFERENT IDs/passwords (or one connection requires and ID/password and another requires no ID/password --- like an Excel or Access connection), and you only configured one of them. In Report Runner Viewer, use the button on the bottom right of the login information window to Add and Advanced Data Connection. This will allow you to set up multiple IDs and passwords. In Report Runner Batch, select the 4th login option in the Job window for multiple IDs. This will add a middle tab to the window that allows you to set up all of your multiple IDs and passwords. These options will also allow you to override the DSN or override the database for a given table, too.
4) Missing DSNs are another big reason your report will not run. It's not the only way, but most Crystal Reports connect to a datasource (SQL Server, Oracle, MySQL) using a DSN. If you run a report on a different machine, that machine must have the exact same DSN created for that datasource.
What is a DSN?: Click Here
If you can't resolve this issue, we ask that you speak with your Crystal Reports developer first, before contacting us. We can not set up the DSNs, and there is no way for our software products to "know" how to set them up for you. If the report is working on another machine in your company, THAT machine will have the DSN configured correctly. Simply copy those settings.
5) The DSN exists, but it's created as a User DSN and not a System DSN. User DSNs are ONLY available to the Windows user that creates the DSN, not to all users. The easiest way to fix this is to NEVER create a User DSN. ALWAYS create a System DSN.
6) An incorrectly named DSN. Your report is looking for "MyDSN - DB1" and you have created one called "MyDSN - SQL". We see this issue A LOT. Our log files show what DSN the report is looking for. Just do a find on "DSN=". You see lines in the log file that look like:
01/01/2011 08:00:00 - Set Login: Server,Path,DSN=MyDSN - DB1
7) On a 64-bit OS you created a DSN, but you created a 64-bit DSN, not a 32-bit DSN. By default on a 64-bit OS, the ODBC Administrator you start is 64-bit and is only capable of creating 64-bit DSNs. You need to go to the C:\Windows\SysWow64 folder and start the ODBC Administrator from that folder (ODBCAD32.EXE). And YES, 32-bit DSNs get created from the SysWow64 folder. It doesn't make sense, but
that's how Microsoft does it. This will create the 32-bit DSNs you need to run the 32-bit version of our software. Note, as of 2013, we DO support 64-bit drivers with our 64-bit edition (available only with an Infinity license), and in that case, you would need 64-bit DSNs and not 32-bit DSNs. Make sure you do not have the same named DSNs in both 64-bit and 32-bit, too.
8) Your reports use an OLE DB connection, not a DSN, and either you simply can not access the connection or the ID and password are wrong. You can test your OLE DB connection external to Crystal Reports and/or Report Runner.
See this KB article. Sometimes, even if the OLE DB connection tests successfully, the report may not work. OLE DB connections are very hard to debug. It may be helpful to temporarily install Crystal Reports on the machine to get the report and connection working, and then removing Crystal Reports. Installing Crystal Reports and testing certain connections also sometimes adds registry entries that make the connection work, too.
9) If your reports connect to Oracle, make sure the machine is configured correctly to connect to Oracle. Your Oracle database administrator can help you with. Most Oracle reports will not run by simply installing our software and running the report. Most Oracle connections require running some kind of Oracle-based installer so the connection can be configured (TNSNames, Net Manager, Oracle Net, etc). It may be helpful to temporarily install Crystal Reports on the machine to get the report and connection working, and then removing Crystal Reports. Installing Crystal Reports and testing certain connections also sometimes adds registry entries that make the connection work, too.
10) Have you tried doing a Database, Verify Database in Crystal Reports? The underlying database structure may have changed since the report was originally developed. Try opening the report in Crystal Reports, and do a Database, Verify Database.
11) Now, SOMETIMES a report doesn't connect to the database correctly, because certain database connection settings in the report are out of sync. Doing a Database, Verify Database will fix some of these. Other times it can be fixed by [Updating] the data connection information, from Database, Set Datasource Location. You can try this EVEN IF YOU'RE UPDATING IT TO THE SAME DATASOURCE. It has a way of resetting the DB connection info in the report.
Here is an external article related to using this UPDATE process.
12) This is an extremely rare one, but
if you use Oracle (notably Oracle 10.2.0.1), and you get a
Database Vendor Code 12154, and you've installed our software on a 64-bit machine, you will want to try uninstalling our software and reinstalling to a different location (keep the data files in the same directory, though). By default, when you install our 32-bit software on a 64-bit machine, it installs the DLLs and Report Runner Unified executable to the Program Files (x86) directory. Oracle sometimes has issues with data connections coming from software running in directories with non-standard characters (like parenthesis). Installing to something like C:\Jeff-Net\Report Runner may fix this issue.
Note: Ignore this #12 tip if you are not on Oracle or if you are not getting a 12154 error. It does not apply to you.
No, seriously. Do not uninstall the software if you are not getting this specific Oracle 12154 error. We know it's tempting, but don't do it.
13) Wrong SQL Client specified/used for DSN; for example SQL Client 11 used instead of SQL Client 10; your error message may look like this:
Invalid Argument provided.
Failed to retrieve data from the database.
Error in File <your-report-name>.rpt:
Invalid argument for database.
14) Unique Crystal runtime service pack differences. As of this article update, there are
well over 20 Crystal runtime engine service packs that have been released. We ship (in the full installer) and recommend SP3 and SP20 as the best and most stable, BUT, we have had a few customers where SP8 or SP13 (or some other service pack) fixed an issue. You may use any service pack that works for you. If, for example, you have 15 machines with our software on it, 10 machines are working just fine, but 5 machines can't run a certain report... and all of the machines and reports are connecting via the same DSN, look at the Crystal runtime engine (service pack) being used on each machine (this is shown in the log file). You may find that the 10 that are working are using SP13, and 5 that aren't working are using SP3. If that's the case, upgrade the 5 machines to SP13.
We have all service packs available for download here:
https://help.reportrunner.com/knowledgebase/article/installing-reinstalling-net-4-or-the-crystal-reports-runtime-engine-manually-and-service-packs
Again, we recommend SP3 or SP20, but you may use any service pack that works for you.
15) Last but not least, your report template could be corrupted. This is not the norm, but it is possible. You're probably going to say, "
But it runs in Crystal Reports!"... yes, but Crystal Reports has a way of auto-correcting some issues in reports that is not possible done in the Crystal runtime engine (which is what our software utilizes). The easiest way to determine if a report is corrupted or not is to create a dummy report using the same DSN, tables, and/or connections. Drop a few fields on the template (don't worry about pretty formatting) and try to run this newly created report. 99% of the time you will see that it works. Lastly, we see a lot of reports become corrupted that were created originally in version 8/8.5 or previous and resaved in 10, then XI, then 2008, etc. It's all the different versions and resaves that corrupts it. This corruption is not anything that SAP will acknowledge, but we know from years and years of experience, it exists.
Another thing to try if the report has multiple sub-reports is to remove the sub-reports one-at-a-time until the report works. That of course, would indicate an issue with that specific sub-report.
---
Did you just skim over this article without really reading it? Please verify each of these common issues. Nine times out of ten, once we schedule a remote session to review these settings, it ends up being one of the easier issues listed above (1-15). And actually, it's not likely that it's not one of the issues above. If it's not listed above, it's probably not fixable.
---
If you are using any of our Report Runner products, it will
show a log of information, and if a table/view/stored procedure is failing to connect, it will indicate which one.
Be sure and include a log file showing the error if/when you submit report data connection issues.
