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 inisde 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.
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 timezone when starting the application.
This is done by passing the system property -Duser.timezone=XYZ
to the application, where XYZ
is the timezone where the computer is located that runs SQL Workbench/J
The timezone 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.
In order to write the proprietary Microsoft Excel format, additional libraries are needed. Please refer to Exporting Excel files for details.
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
If you experience problems when running SQL Workbench/J (or other Java/Swing based applications) on the Windows® platform, this might be due to problems with the graphics driver and/or the DirectDraw installation. If upgrading the graphics driver or the DirectDraw/DirectX version is not an option (or does not solve the problem), try to run SQL Workbench with the direct draw feature turned off:
java -Dsun.java2d.noddraw=true -jar sqlworkbench.jar
When using the exe launcher, you can use the following syntax:
SQLWorkbench -noddraw
If you run SQL Workbench/J through a program that enables remote access to a Windows® workstations (PC-Duo, VNC, NetMeeting, etc), you may need to disable the use of DirectDraw for Java as well.
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 Enable animated icons for details. A different icon (not animated) will be used if that option is disabled.
→ See
Due to a bug in Oracle's JDBC driver, you cannot retrieve columns with
the LONG
or LONG RAW
data type if the DBMS_OUTPUT
package is enabled.
In order to be able to display these columns, the support for DBMS_OUTPUT
has to be switched off using the DISABLEOUT command
before runnnig a SELECT
statement that returns LONG
or LONG RAW
columns.
SQL Workbench/J supports reading and writing BLOB data in
various ways. The implementation relies on standard JDBC API calls
to work properly in the driver. If you experience problems when updating
BLOB columns (e.g. using the enhanced UPDATE, INSERT
syntax or the DataPumper)
then please check the version of your Oracle JDBC driver. Only 10.x drivers
implement the necessary JDBC functions properly. The version of your driver
is reported in the log file when you make a connection to your Oracle server.
By default Oracle's JDBC driver does not return comments made on columns or tables
(COMMENT ON ..
). Thus your comments will not be shown in the database
explorer.
To enable the display of column comments, you need to pass the property remarksReporting
to the driver.
In the profile dialog, click on the remarksReporting
and the value true
. Now close the dialog by clicking on the OK button.
Turning on this features slows down the retrieval of table information e.g. in the Database Explorer.
When you have comments defined in your Oracle database and use the WbSchemaReport command, then you have to enable the remrks reporting, otherwise the comments will not show up in the report.
A DATE
column in Oracle always contains a time as well. If you are not seeing
the time (or just 00:00:00) for a date column but you know there is a different time stored, please enable the
option "Oracle DATE as Timestamp" in the "Data formatting" section of the Options dialog
( → )
The content of columns with the data type XMLTYPE
cannot be displayed by SQL Workbench/J because
the Oracle JDBC driver does not support JDBC's XMLType and returns a proprietary implementation that can only be
used with Oracle's XDB extension classes.
The only way to retrieve and update XMLType columns using SQL Workbench/J is to cast the columns to a CLOB
value e.g. CAST(xml_column AS CLOB)
or to_clob(xml_column)
In the DbExplorer you can customize the generated SQL statement to automatically convert the XMLType to a CLOB. Please refer to the chapter Customize data retrieval in the DbExplorer for details.
Note
When running statements that contain single line comments that are not followed by a space
the following Oracle error may occur:
ORA-01009: missing mandatory parameter [SQL State=72000, DB Errorcode=1009]
.
--This is a comment SELECT 42 FROM dual;
When adding a space after the two dashes the statement works:
-- This is a comment SELECT 42 FROM dual;
This seems to be a problem with old Oracle JDBC drivers (such as the 8.x drivers). It is highly recommend to upgrade the driver to a more recent version (10.x or 11.x) as they not only fix this problems, but are in general much better than the old versions.
It seems that the necessary API calls to list the tables of the INFORMATION_SCHEMA
database (which is a database, not a schema - contrary to its name) are not implemented correctly
in earlier JDBC drivers of MySQL. Only the driver with the version 5.1.7 returns the list of tables
of the INFORMATION_SCHEMA
database.
In case you receive an error message "Operation not allowed after ResultSet closed
"
please upgrade your JDBC driver to a more recent version. This problem was fixed with the MySQL JDBC
driver version 3.1. So upgrading to that or any later version will fix this problem.
MySQL allows the user to store invalid dates in the database (0000-00-00). Since
version 3.1 of the JDBC driver, the driver will throw an exception when trying to retrieve
such an invalid date. This behaviour can be controlled by adding an extended property
to the connection profile. The property should be named zeroDateTimeBehavior
. You can
set this value to either convertToNull
or to round
. For details
see http://dev.mysql.com/doc/refman/4.1/en/connector-j-installing-upgrading.html
SQL Workbench/J retrieves the view definitioin from INFORMATION_SCHEMA.VIEWS
.
In some cases the column VIEW_DEFINITION
does not contain the view definition
and thus the source cannot be displayed.
This error usually occurs in the DbExplorer if an older Microsoft JDBC Driver is used and the connection does not use autocommit mode. There are three ways to fix this problem:
;SelectMethod=Cursor
to your JDBC URLThe possible parameters for the SQL Server 2005 driver are listed here: http://msdn2.microsoft.com/en-us/library/ms378988.aspx
Microsoft SQL Server (at least up to 2000) does not support concurrent reads and writes
to the database very well. Especially when using DDL statements, this can lead to
database locks that can freeze the application. This affects e.g. the display of the tables
in the DbExplorer. As the JDBC driver needs to issue a SELECT statement to retrieve the table
information, this can be blocked by e.g. a non-committed CREATE ...
statement as that will lock the system table(s) that store the meta information about tables
and views.
Unfortunately there is no real solution to blocking transactions e.g. between a SQL tab and the DbExplorer. One (highly discouraged) solution is to run in autocommit mode, the other to have only one connection for all tabs (thus all of them share the same transaction an the DbExplorer cannot be blocked by a different SQL tab).
The Microsoft JDBC Driver supports a connection property called lockTimeout
.
It is recommended to set that to 0 (zero) (or a similar low value). If that is done, calls
to the driver's API will through an error if they encounter a lock rather than waiting
until the lock is released. The jTDS driver does not support such a property. If you are using
the jTDS driver, you can define a post-connect script that
runs SET LOCK_TIMEOUT 0
.
The jTDS driver and the Microsoft JDBC driver read the complete result set into memory before returning it to the calling application. This means that when retrieving data, SQL Workbench/J uses (for a short amount of time) twice as much memory as really needed. This also means that WbExport will effectively read the entire result into memory before writing it into the output file. For large exports this us usually not wanted.
This behaviour of the drivers can be changed by adding an additional parameter to the
JDBC URL that is used to connect to the database. For the jTDS driver append
useCursors=true
to the URL, e.g.
jdbc:jtds:sqlserver://localhost:2068;useCursors=true
.
The URL parameters for the jTDS driver are listed here: http://jtds.sourceforge.net/faq.html#urlFormat
For the Microsoft driver, use the parameter selectMethod=cursor
to
switch to a cursor based retrieval that does not buffer all rows within the driver, e.g.
jdbc:sqlserver://localhost:2068;selectMethod=cursor
.
The URL parameters for the Microsoft driver are listed here: http://msdn2.microsoft.com/en-us/library/ms378988.aspx
When using the DB2 JDBC drivers it is important that the charsets.jar
is part of the used JDK (or JRE). Apparently the DB2 JDBC driver needs this library in
order to correctly convert the EBCDIC characterset (used in the database) into the
Unicode encoding that is used by Java.
The library charsets.jar
is usually included in all multi-language
JDK/JRE installations.
If you experience intermittent "Connection closed" errors when running SQL statements,
please verify that charsets.jar
is part of your JDK/JRE installation.
This file is usually installed in jre\lib\charsets.jar
.
The content of columns with the data type XML
are not displayed in the DbExplorer
(but something like com.ibm.db2.jcc.am.ie@1cee792
instead) because the driver does not convert
them to a character datatype. To customize the retrieval for those columns, please
refer to the chapter Customize data retrieval in the DbExplorer.
When using a JDBC4 driver for DB2 (and Java 6), together with SQL Workbench/J build 107, XML content will be displayed directly without the need to cast the result.
When running SQL statements in SQL Workbench/J and an error occurs, DB2 does not show a proper error message.
To enable the retrieval of error messages by the driver you have to set the extended
connection property retrieveMessagesFromServerOnGetMessage
to true
.
The connection properties for the DB2 JDBC driver are documented here:
example claims that this property is only needed for z/OS, but it works as described for LUW as well.
REORG, RUNSTATS and other db2 command line commands cannot be be run directly through a JDBC interface because
those are not SQL statements, but DB2 commands. To run such a command from with SQL Workbench/J you have to use the
function sysproc.admin_cmd()
. To run e.g. a REORG on a table you have to run the following statement:
call sysproc.admin_cmd('REORG TABLE my_table');
The PostgreSQL JDBC driver defaults to buffer the results obtained from the database in memory before returning them to the application. This means that when retrieving data, SQL Workbench/J uses (for a short amount of time) twice as much memory as really needed. This also means that WbExport will effectively read the entire result into memory before writing it into the output file. For large exports this us usually not wanted.
This behaviour of the driver can be changed so that the driver uses cursor based retrieval. To do this, the connection profile must disable the "Autocommit" option, and must define a default fetch size that is greater than zero. A recommended value is e.g. 10, it might be that higher numbers give a better performance. The number defined for the fetch size, defines the number of rows the driver keeps in its internal buffer before requesting more rows from the backend.
More details can be found in the driver's manual: http://jdbc.postgresql.org/documentation/83/query.html#query-with-cursor
PostgreSQL - unlike other DBMS - marks a complete transaction as failed if a single statement fails. In such a case the transaction cannot be committed, e.g. consider the following script:
INSERT INTO person (id, firstname, lastname) VALUES (1, 'Arthur', 'Dent'); INSERT INTO person (id, firstname, lastname) VALUES (2, 'Zaphod', 'Beeblebrox'); INSERT INTO person (id, firstname, lastname) VALUES (2, 'Ford', 'Prefect'); COMMIT;
As the ID column is the primary key, the third insert will fail with a unique key violation.
In PostgreSQL you cannot commit anyway and thus persist the first two INSERT
s.
This problem can only be solved by using a SAVEPOINT before and after each statement. In case that statement fails, the transaction can be rolled back to the state before the statement and the reminder of the script can execute.
Doing this manually is quite tedious, so you can tell SQL Workbench/J to do this automatically for you by setting the properties:
workbench.db.postgresql.ddl.usesavepoint=true workbench.db.postgresql.sql.usesavepoint=true
in the file workbench.settings. If this is enabled,
SQL Workbench/J will issue a SET SAVEPOINT
before running each statement
and will release the savepoint after the statement. If the statement failed, a rollback to the
savepoint will be issued that will mark the transaction as "clean" again. So in the above
example (with sql.usesavepoint
set to true
), the last
statement would be rolled back automatically but the first two INSERT
s
can be committed (this will also required to turn on the "Ignore errors" option is enabled).
If you want to use the modes update/insert
or
insert/update
for WbImport, you should also add the
property:
workbench.db.postgresql.import.usesavepoint=true
to enable the usage of savepoints during imports. This setting also affects
the WbCopy
command.
You can also use the parameter -useSavepoint
for the
WbImport
and WbCopy
commands to control the use of
savepoints for each import.
Using savepoints can slow down the import substantially.
nvarchar
are not displayed properly
The jConnect driver seems to have a problem with nvarchar
columns. The data type is not reported properly by the driver,
so the display of the table structure in the DbExplorer will be wrong for those columns.