34. Common DBMS problems
Prev |  | Next

## 34. Common DBMS problems

### 34.1. Oracle

#### 34.1.1. No Views or tables visible in the DbExplorer

Since Build 112 it is possible that the DbExplorer does no longer display views or tables if the selected schema (username) contains an underscore. This is caused by a bug in older Oracle JDBC drivers.

The driver calls used to display the list of tables and views in a specific schema expects a wildcard expression. To avoid listing the objects for `USERX1` when displaying the objects for `USER_1` the underscore must be escaped. The driver will create an expression similar to `AND owner LIKE 'USER_1' ESCAPE '\'` (which would return tables for `USERA1`, `USERB1` and so on, including of course `USER_1`).

The character that is used to escape the wildcards is reported by the driver. SQL Workbench/J sends e.g. the value `USER\_1` if the driver reports that a backslash is used to escape wildcards.

However some older Oracle drivers report the wrong escape character, so the value sent to the database results in `AND owner LIKE 'USER\_1' ESCAPE '/'`. The backslash in the expression is the character reported by the driver, whereas the forward slash in the expression is the character actually used by the driver.

To fix this problem, the escape character reported by the driver can be overridden by setting a property in `workbench.settings`:

`workbench.db.oracle.searchstringescape=/`

You can also change this property by running

    WbSetConfig workbench.db.oracle.searchstringescape=/

This bug was fixed in the 11.2 drivers.

#### 34.1.2. Error: "Stream has already been closed"

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 running a `SELECT` statement that returns `LONG` or `LONG RAW` columns.

#### 34.1.3. BLOB support is not working properly

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.

#### 34.1.4. Table and column comments are not displayed

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 Extended Properties button. Add a new property in the following window with the name `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 remarks reporting, otherwise the comments will not show up in the report.

#### 34.1.5. Time for DATE columns is not displayed

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 (Tools → Options)

#### 34.1.6. Content of XMLTYPE columns is not displayed

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

#### 34.1.7. Error: "missing mandatory parameter"

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 (11.x or 12.x) as they not only fix this problems, but are in general much better than the old versions.

#### 34.1.8. Connection is closed after cancelling a statement

If the Oracle server closes the connection after cancelling a statement, this can be fixed (in some installations) by adding the following extended property to the connection profile:

`oracle.net.disableOob=true`

### 34.2. MySQL

#### 34.2.1. INFORMATION_SCHEMA tables not displayed in DbExplorer

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 some versions of the MySQL driver. Currently only the version 5.1.30 is known to return the list of tables of the `INFORMATION_SCHEMA` database.

#### 34.2.2. "Operation not allowed" error message

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.

#### 34.2.3. Problems with zero dates with MySQL

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 behavior 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/connector-j/en/connector-j-reference-configuration-properties.html

To ignore errors

#### 34.2.4. The SQL source for views is not displayed

SQL Workbench/J retrieves the view definition from `INFORMATION_SCHEMA.VIEWS`. For some unknown reason, the column `VIEW_DEFINITION` sometimes does not contain the view definition and the source is not displayed in the DbExplorer.

To make SQL Workbench/J use MySQL's `SHOW CREATE VIEW` statement instead of the `INFORMATION_SCHEMA`, you can set the property `workbench.db.mysql.use.showcreate.view` to true, e.g. by running `WbSetConfig workbench.db.mysql.use.showcreate.view=true`

#### 34.2.5. No table comments are displayed in the DbExplorer

In order for MySQL's JDBC driver to return table comments, the connection property `useInformationSchema` must be set to true.

For details please see this bug report: http://bugs.mysql.com/bug.php?id=65213

### 34.3. Microsoft SQL Server

#### 34.3.1. The value of DATE columns is not correct

It seems that the version 3.0 of the Microsoft JDBC driver returns the value of `DATE` columns with a wrong value (two days less than expected).

Version 4.0 of the Microsoft driver does not show this behavior. If you see wrong values for `DATE` columns and are using version 3.0, please upgrade your driver.

#### 34.3.2. Column and table comments are not displayed

SQL Server does not support standard object remarks using `COMMENT ON` and the JDBC drivers (jTDS and Microsoft's driver) do not return the so called "extended attributes" through the JDBC API calls. To retrieve table and column remarks that are defined through the stored procedure `sp_addextendedproperty()`, SQL Workbench/J must run additional statements to retrieve the extended properties. As these statements can impact the performance of the DbExplorer, this is turned off by default.

To turn the retrieval of the extended properties on, please configure the necessary properties. For details, see the section Retrieving remarks for Microsoft SQL Server.

#### 34.3.3. Using Windows authentication to connect to a SQL Server

In order to use the integrated Windows authentication (as opposed SQL Server Authentication) the Microsoft JDBC driver is required. It does not work with the jTDS driver.

When using Windows authentication the JDBC driver will try to load a Windows DLL named `sqljdbc_auth.dll`. This DLL either needs to be on the Windows `PATH` definition or in the directory where `SQLWorkbench.exe` is located. You need to make sure that you use the correct "bit" version of the DLL. If you are running a 32bit Java Runtime you have to use the 32bit DLL. For a 64bit Java Runtime you need to use the 64bit DLL (the architecture of the server is not relevant).

#### 34.3.4. The Microsoft Driver throws an Exception when using SET SHOWPLAN_ALL

When displaying an execution plan using `SET SHOWPLAN_ALL ON` and the following error is thrown: `The TDS protocol stream is not valid. Unexpected token TDS_COLMETADATA (0x81).` please set "Max. Rows" to 0 for that SQL panel. Apparently the driver cannot handle showing the execution plan and having the result limited.

#### 34.3.5. Dealing with locking problems

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`.

#### 34.3.6. Can't start a cloned connection while in manual transaction mode

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:

- Upgrade to a newer Microsoft driver (e.g. the one for SQL Server 2005)
- Enable autocommit in the connection profile
- Add the parameter `;SelectMethod=Cursor` to your JDBC URL

This article in Microsoft's Knowledgebase gives more information regarding this problem.

The possible parameters for the SQL Server 2005 driver are listed here: http://msdn2.microsoft.com/en-us/library/ms378988.aspx

#### 34.3.7. WbExport or WbCopy using a lot of memory

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 or WbCopy will effectively read the entire result into memory before writing it into the output file. For large exports this us usually not wanted.

This behavior 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`

Note that since Version 3.0 of the driver

The URL parameters for the Microsoft driver are listed here: http://msdn2.microsoft.com/en-us/library/ms378988.aspx

#### 34.3.8. Sequences are incremented twice

When a sequence is incremented twice when running `SELECT NEXT VALUE FOR MYSEQ;` and you are using the Microsoft JDBC driver with the `selectMethod=cursor`, remove the `selectMethod=cursor` option from the JDBC URL. The sequences will then be incremented correctly.

### 34.4. IBM DB2

#### 34.4.1. Date values are not displayed

If date values are not displayed (show up as blank or null) in the results, you have to add the parameter `;date format=iso` to your JDBC connection URL. Note the blank between `date` and `format`.

See IBM's FAQ for details: http://www-03.ibm.com/systems/i/software/toolbox/faqjdbc.html#faqB5

#### 34.4.2. "Connection closed" errors

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`.

#### 34.4.3. XML columns are not displayed properly in the DbExplorer

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.

#### 34.4.4. No error text is displayed

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:

http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.apdv.java.doc/src/tpc/imjcc_rjvdsprp.html?lang=en
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzahh/jdbcproperties.htm?lang=en

#### 34.4.5. Displaying column headers instead of column names in result sets.

When running SQL statements in SQL Workbench/J you might want to use the long column headings (created via `LABEL ON`) as opposed to the column name. To enable the retrieval of error messages by the driver you have to set the extended connection property `extended metadata` to `True`.

The connection properties for the DB2 JDBC driver are documented here:

http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.apdv.java.doc/src/tpc/imjcc_rjvdsprp.html?lang=en
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzahh/jdbcproperties.htm?lang=en

#### 34.4.6. Column or table comments are not displayed

The DB2 JDBC driver does not return the column description stored in SYSCOLUMNS.COLUMN_TEXT, or SYSTABLES.TABLE_TEXT. If you are using these descriptions, you can enable retrieving them (and overwriting the comments returned by the driver) by setting the following two configuration properties to `true` (e.g. using WbSetConfig)

`workbench.db.db2i.remarks.columns.use_columntext` for column comments
`workbench.db.db2i.remarks.tables.use_tabletext` for table comments

#### 34.4.7. DB2 commands like REORG cannot be run

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 within 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');

### 34.5. Amazon Redshift

#### 34.5.1. "ERROR: type "e" does not exist" when using the DbExplorer

This error occurs when using a Postgres JDBC driver with Amazon Redshift.

For Redshift, the Redshift driver should be used: http://docs.aws.amazon.com/redshift/latest/mgmt/configure-jdbc-connection.html

### 34.6. PostgreSQL

#### 34.6.1. High memory usage

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 or WbCopy will effectively read the entire result into memory before writing it into the output file. For large exports this us usually not wanted.

This behavior 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. 100, 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: https://jdbc.postgresql.org/documentation/query/#getting-results-based-on-a-cursor

### 34.7. Sybase SQL Anywhere

#### 34.7.1. Columns with type `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.

Prev |  | Next
33. Common problems | Home | 35. Options dialog