SQL0332N Character conversion from the source code page "0" to the target code page "<database codepage>" is not supported
SQL0332N error received when executing CLI application using a DB2 Client or Driver from DB2 Version 9.7 fix pack 6 (18.104.22.168), or DB2 Version 9.7 fix pack 5 (22.214.171.124).
Two scenarios may generate this symptom:
1. When connection string passed to SQLDirverConnect() contains an invalid attribute that results only in a warning message CLI004W. The connection to the database would be successful with warning (SUCCESS_WITH_INFO), but several of the DB2 CLI APIs against this database may throw the -332 error further down the application logic. The problem has been seen with SQLGetCursorName() API
2. When attempting to access a DRDA nickname in a Federation Server environment with trusted context connection enabled. Though most of statements that access the nickname would be successful, several of them may fail with the -332 error.
-DELETE FROM <nickname> WHERE (SELECT * FROM <nickname> FETCH FIRST N ROWS ONLY)
-UPDATE <nickname> SET set_clause (NOTE: problem happens if set_clause cannot be pushed down to remote)
-DELETE FROM <nickname> WHERE CURRENT OF <CURSOR NAME>
-UPDATE <nickname> SET set_clause WHERE CURRENT OF <CURSOR NAME>
Following is an example of the symptom that may be received:
SQL0332N Character conversion from the source code page "0" to the target code page "1202" is not supported."
The cause of the symptom in this environment is DB2 APAR IC84944. CLI attempts to convert data from codepage 0 to codepage <decided by target db>, and conversion from codepage 0 to any valid codepage is invalid.
CLI applications using either a client or driver from DB2 Version 9.7 fix pack 6 (126.96.36.199), or DB2 Version 9.7 fix pack 5 (188.8.131.52) on Linux, UNIX, or Windows platforms.
Diagnosing the problem
- SQL0332N error seen either with an invalid connection string attribute or with trusted context enabled in a federated environment.
- Use a CLI Trace from the client application to check if the SQLGetCursoName encountered the error. Check for the following entries:
SQLGetCursorNameW( hStmt=1:1, pszCursor=&00aef244, cbCursorMax=2374,pcbCursor=&00aefb94 )
---> Time elapsed - +8,320000E-004 seconds
<--- SQL_ERROR Time elapsed - +1,108400E-002 seconds
SQLFetch( hStmt=1:1 ) ---> Time elapsed - +1,551000E-003 seconds
( Unretrieved error message="[IBM][CLI Driver][DB2/NT] SQL0332N
Character conversion from the source code page "0" to the target
code page "1202" is not supported." )
<--- SQL_NO_DATA_FOUND Time elapsed - +2,558000E-003 seconds
Resolving the problem
The resolution for this issue is to apply the fix for APAR IC84944 to the client system receiving the error. Please review the APAR link to check which fix pack the fix was delivered in.
Use this workaround if you are unable to apply the fix pack that contains the fix to the APAR:
- If SQLDriverConnect() results in a warning, then check if connection string passed to it has any invalid parameter or keyword specified. If so, then either remove the invalid parameter or correct it.
- Create user mapping using different users for federated database and remote data source.
Suppose you have USER1 as user for federated database and USER2 as user for remote data source, then :
CREATE SERVER "<SERVER1>" TYPE db2/UDB VERSION 9.7 WRAPPER "DRDA" AUTHORIZATION "<USER2>" PASSWORD"<PASSWD1>" options(dbname 'UDB', FED_PROXY_USER '<USER1>');
CREATE USER MAPPING FOR <USER1> SERVER "<SERVER1>" OPTIONS( REMOTE_AUTHID '<USER2>', REMOTE_PASSWORD '<PASSWD2>', USE_TRUSTED_CONTEXT 'Y')
More support for:
DB2 for Linux, UNIX and Windows
DB2 Programming Interfaces - CLI
Software version: 9.7
Operating system(s): AIX, HP-UX, Linux, Solaris, Windows
Reference #: 1600269
Modified date: 2012-07-04