Database Connectivity Errors
The most common problems encountered with a new JasperReports Server instance are database configuration problems. The connection may fail because the application server can't find the driver for the data source. For example, in a default installation of JasperReports Server, Tomcat looks for data source drivers in <js‑install>/apache-tomcat/lib. If the driver's in a different location, put a copy of the driver in this directory and restart Tomcat.
Testing the Database Connection
The simplest database configuration problem is an incorrect user name or password. If you encounter database problems upon startup or login, check the user name and password by logging directly into your RDBMS as described below.
You can connect to your database using the database configuration settings in JasperReports Server. This validates the database hostname, port, username, and password.
If you're having trouble logging into JasperReports Server on the login page, check the existing users and passwords in the jasperserver.JIUser table.
Logging into PostgreSQL
Run the PostgreSQL client from the command line and try to connect to the database. For example:
psql -U postgres jasperserver
Logging into MySQL
Run the MySQL client from the command line and try to log in directly as the root user, for example:
<mysql>/bin/mysql -u root -p
You're prompted for the password of the user you specified on the command line.
Logging into Oracle
Start SQL*Plus and try logging into Oracle directly. Use the password specified during installation to log in as each of these users:
• | jasperserver — schema user for the JasperReports Server metadata. |
• | sugarcrm — schema user for the SugarCRM sample data. |
• | foodmart — schema user for the foodmart sample data. |
Logging into Microsoft SQL Server
Run the sqlcmd and try logging into MSSQL Server directly. For example:
sqlcmd -S localhostjasperserver -d jasperserver -U jasperadmin -P password
Connectivity Errors with Vendor's Driver for SQL Server
If you're using the vendor's driver for SQL Server and have configured default_master.properties as described in SQL Server Example, you'll see connection errors if you uncommented the following line:
# admin.jdbcUrl=jdbc:sqlserver://${dbHostOrInstance};SelectMethod=cursor[/code] |
Make sure this line is commented.
Case-sensitive Collation in SQL Server
Microsoft SQL Server doesn't support standalone case-sensitive collation. When collation is case-sensitive SQL Server also treats column and table names as case-sensitive. This can happen when setting a locale that includes case‑sensitive collation. In this case you may see an error such as the following.
Use a different locale or remove the case-sensitivity setting.
Maximum Packet Size in MySQL
If you're upgrading or importing into a MySQL database and your repository contains large objects like images, you may see an error like this:
ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes
The default max_allowed_packet on the MySQL server is 1M (one Megabyte = 1,048,576 bytes). The most effective fix is to change this value in the server configuration to accommodate the largest resource stored in your repository. The server configuration file is typically named my.cnf (or my.ini) and located in the MySQL root directory, but this may vary. Change the configuration setting to a larger value, for example:
max_allowed_packet = 16M
For more information, see http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html.
After changing this value, restart the MySQL server. Then perform the upgrade or import step again.
Connection reset by peer MySQL Error
If you are using the MariaDB JDBC driver to connect to the MySQL database and get an error like:
Could not send query:Connection reset by peer: socket write error [/code] |
This message refers to the maximum packet size error described above. Follow those instructions.
Case Sensitivity for Table and Column Names
In some databases, table names are case-sensitive and “customer” and “Customer” are two different tables.
If you're using a case-sensitive database for JasperReports Server, table names specified in query strings in the JRXML file of a saved report must match the table names used in the database. A mismatch when transferring data from one database to another may cause the capitalization of table names to change.
In Windows MySQL, table and column names are not case-sensitive.
In Linux MySQL, table and column names are case-sensitive. You can configure Linux MySQL to be non-case-sensitive by setting the configuration parameter lower_case_table_names to 1 in the my.ini or my.cnf file. For more information search the MySQL documentation for a section about identifier case sensitivity.
Table and column names in Oracle and PostgreSQL are case-sensitive.
PostgreSQL: Job Scheduling Error
If the Quartz settings in the PostgreSQL database aren't updated to specify the driver delegate class specific to PostgreSQL you'll get errors when you try and run a scheduled report.
The errors will look like this:
If you see this error, check your Quartz properties file in the following location:
<tomcat>/webapps/jasperserver-pro/WEB-INF/js.quartz.properties
Make sure the following property does not have the standard driver delegate, but instead has the PostgreSQL-specific driver delegate. It should look like the following for PostgreSQL:
quartz.delegateClass=org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
Invalid SQL statement Error with TIBCO JDBC Driver Under WebLogic
When you set up a TIBCO JDBC driver in the WebLogic console, you need to make sure the Test Table Name property is empty. WebLogic inserts SQL null in this property by default.
If you don't delete this when setting up the driver, you'll get errors like:
Test "null" set up for pool "JasperserverDataBase" failed with exception:"java.sql.SQLSyntaxErrorException: [TIBCO][Oracle JDBC Driver][Oracle]ORA-00900: invalid SQL statement[/code] |
If you get this error, you need to use the WebLogic console to edit or recreate the driver for each database that failed. See Configuring Other Database Connections.
Performance Issues with Oracle JDBC Queries
Setting the Oracle database localization option defaultNChar to true can substantially impact the performance of JDBC queries. When defaultNChar is set to true, the database implicitly converts all CHAR data to NCHAR when you access CHAR columns. If you don't need to support UTF-8 for your Oracle database, you can omit this setting.
The option you need and how to set it depends on your version of Java, your application server, and how it's deployed. For information about changing a JVM option setting for your particular environment, see your application server documentation.
To change this setting on Windows, enter a command like this at the command line:
set JAVA_OPTS=%JAVA_OPTS% -Doracle.jdbc.defaultNChar=false
To change this setting on Linux, enter a command like this at the command line:
export JAVA_OPTS="$JAVA_OPTS -Doracle.jdbc.defaultNChar=false"
Using an Oracle Service Name
If your Oracle database is configured to use a service name instead of an Oracle system identifier (SID), set up the service name by updating your default_master.properties file before using buildomatic:
<js-install>/buildomatic/default_master.properties
In default_master.properties, uncomment the serviceName property and enter your Oracle service name, for example:
serviceName=ORCL
When you're using an Oracle service name, make sure you don't set the SID or dbPort in the default_master.properties file.
Error Running a Scheduled Report
If you run a scheduled report and save it as HTML or RTF, the resulting report may be quite large. If you are running MySQL and get the error shown here, the problem may be the default size of the MySQL blob datatype.
JDBC exception on Hibernate data accessorg.hibernate.exception.GenericJDBCException: could not insert[/code] |
You can increase the size of this datatype by updating your my.ini or my.cnf MySQL configuration file with the following setting:
max_allowed_packet=32M
Error Running a Report
If you can log into JasperReports Server but encounter an error when running a report, browse the repository to identify and resolve the problem.
One common problem with an individual report is the data source. To validate a data source connection:
1. | Log into JasperReports Server as a user with administrative permissions and locate the report unit that returns errors. |
2. | Select the report and click the Edit button in the toolbar and identify the data source on the fourth edit page. |
3. | Edit the data source in the repository and check its settings. |
4. | Click the Test Connection button. |
If the connection fails, perhaps the application server can't find the driver for the data source. For example, in a default installation of JasperReports Server, Tomcat looks for data source drivers in <js‑install>/apache-tomcat/lib.
5. | Test your report. If it still returns errors, edit the data source again and try checking other values, like the port used by the database. |
Save Error with DB2 Database
When the DB2 database is your repository database, you may get errors when saving longer strings (over 50 characters) to data entry fields in the UI. For example, saving a resource with a name over 50 characters may cause an error like this:
Expected status code is 200, but was 400. Response body contained:An unexpected exception has occurred[/code] |
The problem here is DB2 handles UTF-8 characters differently than other Jaspersoft certified databases. When DB2 is used as the repository database, it limits the number of characters that can be entered in UI fields. The database columns holding these strings need to be made larger.
BeanDefinitionStoreException with DB2 with Vendor's Driver
If you're using the vendor's driver for DB2, you need to manually add properties to default_master.properties, or you'll get an error like the following.
Add the following properties to your default_master.properties, setting the correct values for your installation:
Recommended Comments
There are no comments to display.