home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
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
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IT06610 Status: Geschlossen

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

Produkt:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problembeschreibung:
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-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* DB2 LUW users                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 10.5 FP7 or later                             * 
****************************************************************
Local-Fix:
Lösung
Problem was first fixed in DB2 10.5 FP7
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
20.01.2015
26.01.2016
26.01.2016
Problem behoben ab folgender Versionen (IBM BugInfos)
Problem behoben lt. FixList in der Version
10.5.0.7 FixList