33. Common problems

33.1. The driver class was not found
33.2. Syntax error when creating stored procedures
33.3. The SQL source code for tables or indexes is incorrect
33.4. Timestamps with timezone information are not displayed correctly
33.5. Some of the dialogs are too small
33.6. Excel export not available
33.7. Generated XLSX files can't be opened with Excel
33.8. Out of memory errors
33.9. High CPU usage when executing statements
33.10. High CPU usage when displaying results

33.1. The driver class was not found

If you get an error "Driver class not registered" or "Driver not found" please check the following settings:

  • Make sure you have specified the correct location of the jar file. Some drivers (e.g. for IBM DB2) may require more than one jar file.

  • Check the spelling of the driver's class name. Remember that it's case sensitive. If you don't know the driver's class name, simply press the Enter key inside the input field of the jar file location. SQL Workbench/J will then scan the jar file(s) to find the JDBC driver

33.2. Syntax error when creating stored procedures

When creating a stored procedure (trigger, function) it is necessary to use a delimiter other than the normal semicolon because SQL Workbench/J does not know if a semicolon inside the stored procedure ends the procedure or simply a single statement inside the procedure.

Therefor you must use an alternate delimiter when running a DDL statement that contains "embedded" semicolons. For details please refer to using the alternate delimiter.

33.3. The SQL source code for tables or indexes is incorrect

SQL Workbench/J re-creates the source code for tables and indexes based on the information returned by the JDBC driver. This does not alway match the original DDL used to create the table or index due to the limited information available by the JDBC API.

If the DBMS supports a SQL query to retrieve the real (native) source of a table or index, the query can be configured to be used instead of the generic reverse engineering built into SQL Workbench/J

Please see the chapter Customize table source retrieval for details on how to configure the query.

33.4. Timestamps with timezone information are not displayed correctly

When using databases that support timestamps or time data with a timezone, the display in SQL Workbench/J might not always be correct. Especially when daylight savings time (DST) is in effect.

This is caused by the handling of time data in Java and is usually not caused by the database, the driver or SQL Workbench/J

If your time data is not displayed correctly, you might try to explicitely specify the time zone when starting the application. This is done by passing the system property -Duser.timezone=XYZ to the application, where XYZ is the time zone where the computer is located that runs SQL Workbench/J

The time zone should be specified relativ to GMT and not with a logical name. If you are in Germany and DST is active, you need to use -Duser.timezone=GMT+2. Specifying -Duser.timezone=Europe/Berlin does usually not work.

When using the Windows® launcher you have to prefix the paramter with -J to identify it as a parameter for the Java runtime not for the application.

33.5. Some of the dialogs are too small

When using non-default font sizes in the operating system, it can happen that the windows shown in SQL Workbench/J are sometimes too small and some GUI elements are cut off or not visible at all.

All windows and dialogs can be resized and will remember their size. If GUI controls are not visible or are cut-off simply resize the window until everything is visible. The next time the dialog is opened, the chose size will be restored.

33.6. Excel export not available

In order to write the proprietary Microsoft Excel format, additional libraries are needed. Please refer to Exporting Excel files for details.

33.7. Generated XLSX files can't be opened with Excel

When using an Oracle JDBC driver together with the needed XDB libraries, the generated XLSX files can't be opened with Excel. This is caused by Oracle's library xmlparserv2.jar that conflicts with the libraries used to generate the XLSX file.

The only fix for this is to not use the Oracle XDB files (i.e. only use the ojdbc8.jar driver file, not the others.

33.8. Out of memory errors

The memory that is available to the application is limited by the Java virtual machine to ensure that applications don't use all available memory which could potentially make a system unusable.

If you retrieve large resultsets from the database, you may receive an error message indicating that the application does not have enough memory to store the data.

Please refer to Increasing the memory for details on how to increase the memory that is available to SQL Workbench/J

Some JDBC drivers also buffer the whole result in memory before returning it to the application. This can lead to high memory requirements for WbExport or WbCopy even though SQL Workbench/J does not need to load the whole result into memory. For Microsoft SQL Server and PostgreSQL this can be avoided by configuring the connection profile.

33.9. High CPU usage when executing statements

If you experience a high CPU usage when running a SQL statement, this might be caused by a combination of the graphics driver, the JDK and the Windows® version you are using. This is usually caused by the animated icon which indicates a running statement (the yellow smiley). This animation can be turned off in ToolsOptions See Enable animated icons for details. A different icon (not animated) will be used if that option is disabled.

33.10. High CPU usage when displaying results

If you experience a high(er) CPU usage when displaying results, this can be caused by enabling the display of multi-line values. If that is the case, turning off that option, can reduce the CPU usage.