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
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.
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.
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.
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.
In order to write the proprietary Microsoft Excel format, additional libraries are needed. Please refer to Exporting Excel files for details.
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.
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.
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 → See Enable animated icons for details. A different icon (not animated) will be used if that option is disabled.
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.