When adding a data source to JasperReports Server, several things can cause errors. Start by looking at the following general connectivity issues:

Many databases, including MySQL, also require the user grants to include the specific host from which connections are allowed. Otherwise, when testing the JDBC connection, a connection may not be allowed even though the username and password are correct. For more information, refer to the MySQL documentation for setting up users.

An easy way to test connectivity from the server to the database with a particular user is to use a tool such as SQuirreL or another DB query tool to connect to the database from the host of your JasperReports Server instance.

Logging JDBC Operations

You can enable additional logging to help you find the cause of the error. Set any or all of the following loggers in the server settings interface or in the .../WEB-INF/log4j.properties file:

JDBC Drivers

JasperReports Server ships with drivers for several databases, as listed in the dialog for creating data sources. If the JDBC driver for your database is not included, the administrator can easily upload the driver and use it immediately in a data source.

Database Permissions

When creating database users, you must ensure that they have the appropriate privileges to access data, as well as permission to connect from the server that JasperReports Server is running on.

A fairly easy way to test permissions and connectivity is to use a tool such as SquirrelSQL or another DB query tool to connect to the database from the same host as JasperReports Server and to run typical queries against your database.

SQL Functions with TIBCO JDBC Drivers

TIBCO provides several JDBC drivers. The TIBCO JDBC drivers are based on the Progress DataDirect Connect drivers and support a slightly different SQL syntax than the vendors' drivers. If you see errors like the one below when running reports or creating domains that use scalar functions, you'll need to modify your queries.

For example, the following query does not work with the TIBCO JDBC drivers:

The correct syntax for the TIBCO JDBC drivers is as follows:

For more information, see the Progress DataDirect page on scalar functions.

JNDI Services on Apache Tomcat

If you have trouble with a JNDI connection, you need to look at the JNDI definition for your database on your application server. This section gives common issues with JNDI definitions on Apache Tomcat connecting to MySQL. If you use a different application server or database server, refer to its documentation.

A JNDI connection on Tomcat is defined in two different files. Make sure both have the following information:

Also check the following points:

JNDI Services on JBoss

Follow these steps to configure JasperReports Server to use JNDI data sources with JBoss:

JNDI Services on WebLogic

Follow these steps to configure JasperReports Server to use JNDI data sources with WebLogic:

Ensure the database user in your JNDI definition has the privileges to run SELECT queries on the tables used in your reports. In some cases, additional permissions may be required to execute stored procedures, depending on your configuration and needs. For more information, see Database Permissions.

Creating a Data Source on SQL Server Using Windows Authentication

If your database is Microsoft SQL Server and you use Windows Authentication (also called Integrated Security), use the following procedure to create a data source.

For Tomcat, this is the <tomcat>bin folder.

For Tomcat, this is the <tomcat>lib folder.

;integratedSecurity=true

Upgrading Bean Data Sources

There was a change in the Spring configuration for JasperReports Server 6.0 which changes how some of the existing Spring beans are made accessible for use by other beans. This can break existing custom data sources. This change specifically affects beans which implement the interface ReportDataSourceServiceFactory.

Prior to release 6.0, if code in JasperReports Server accessed a bean of this type, it would get the actual instance of the Spring bean as configured in the Spring XML file, and it could be cast to the concrete class. In 6.0 and later, these beans were intercepted in order to implement the profile attributes feature, and instead of seeing the actual instance, other code would see a dynamic proxy instead of the actual bean.

Dynamic proxies are a Java feature which allows classes to be generated at run time that implement any interface that can be loaded on the classpath. The resulting object can be cast to any of those interfaces, but doesn't correspond to any concrete class. For more information:

http://www.javaworld.com/article/2076233/java-se/explore-the-dynamic-proxy-api.html

Since proxies can only represent interfaces, existing code that tries to cast the bean to a concrete class will break. Casting is usually done to get access to methods on a more specific class or interface. As long as the code is not casting the bean to a concrete class, it will work, so there are two ways to get around this problem:

For example, let's say you have a bean with id myBean that needs to access the jdbcDataSourceServiceFactory, configured as follows:

Where myBean has the following Spring configuration:

The following code worked before but will now cause an error:

Because the first call is a method which is part of the ReportDataSourceServiceFactory, the cast is unnecessary; to fix it, just leave it out:

In this example, JdbcReportDataSourceServiceFactory has a method called doSomethingElse(). This method is not part of any interface, but you can create an interface that includes it:

JdbcReportDataSourceServiceFactory would need modification so that itimplements this new interface:

You don't have to change the declaration in MyBean because Spring will generate a dynamic proxy implementing MyDSSF, but if you change the declaration, the code will be easier to understand because no casts will be necessary: