home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IT06610 Status: Closed

STATIC SQL APPLICATIONS RUNNING IN A UNEQUAL CODEPAGE ENVIRONMENTS MAY
RETURN ERROR SQL0302N

product:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problem description:
If you have a static SQL application defined in a different code 
page from the database, you may get error SQL0302N. 
 
This APAR will introduce a new BIND option : 
 
HV_EXPANSION_FACTOR <1|2|3|4> 
 
Used to indicate a multiplier be applied to CHAR and VARCHAR 
host variable length. 
 
The bind option HV_EXPANSION_FACTOR can be used to expand 
character host 
variable lengths within database server to accommodate code page 
conversion 
expansion in unequal codepage environments (eg. 819 client and 
UTF-8 database) 
 
Targeted to resolve -302 errors occurring in static SQL 
applications running in unequal codepage environments even after 
table definitions increased to accommodate expansion 
 
Static SQL by default uses the defined length of the host 
variable provided by the client during BIND to size the 
equivalent database server memory location for the variable 
 
With this bind option, the database server memory size can be 
enlarged to accommodate expansion 
 
Example : 
819 codepage application with string "ni&#241;o" requires a 4 byte 
character string variable in the application. However in unicode 
UTF-8 the string requires 5 bytes as ?&#241;? takes 2 bytes to 
represent. 
So if you have an application running codepage 819 connecting to 
an unicode (utf-8) database you may run : 
 
db2 "bind myapp GENERIC 'HV_EXPANSION_FACTOR 2'" 
 
This will force the database to allocate 2 times the defined 
application length for the server representation of the 
variable.  So in this example the 4 byte variable becomes 8 
bytes in the database server. 
 
As a result, the string "ni&#241;o" expands to 5 bytes in UTF-8 
still fits in the memory available to the variable
Problem Summary:
**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 LUW users                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 10.5 FP7 or later                             * 
****************************************************************
Local Fix:
Solution
Problem was first fixed in DB2 10.5 FP7
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
20.01.2015
26.01.2016
26.01.2016
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)
10.5.0.7 FixList