VARCHAR und Character Conversion
- Dieses Thema hat 3 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 14 Jahre, 4 Monaten von
Anonym.
-
AuthorPosts
-
27. April 2009 um 22:08 Uhr #4034
AnonymInaktivHallo zusammen,
wir haben einen DB2-Server V9.1 unter UFT-8 laufen.
Der Client läuft unter Latin1.
Eine varchar(2000)-Spalte nimmt netto 2000 Bytes auf, d.h. wird ein Latin1-Zeichen zu einer 2Byte-Repräsentation, so können nicht 2000 Zeichen gespeichert werden. Z.B. passen hier nur 1000 ‚ä‘ hinein.Ich hoffte nun mit der Deklaration varchar(2000) for bit data tatsächlich den Zugriff auf 2000 Bytes zu bekommen. Wie bekomme ich es jetzt auf dem Latin1-Client hin, dass die Byte-Repräsentation eines ‚ä‘ unter Latin1 genau so ohne Konvertierung in der Datenbank landet?
Gibt es eine andere Möglichkeit wirklich Byte-Daten in VARCHAR abzulegen?
Gruß
Andreas
29. April 2009 um 20:10 Uhr #4204
AnonymInaktivHallo Andreas,
ich kann Deine Fragen nicht ganz nachvollziehen. Das Thema ist aber sicher eines der schwierigsten in der IT.
Deswegen erst mal der obligatorische Link: Understanding DB2 Universal Database character conversion: http://www.ibm.com/developerworks/data/library/techarticle/dm-0506chong/index.html.
Warum sollte plötzlich ein Single Bytes (SBCS) zu einem Double Byte (DBCS) werden?
Mit FOR BIT DATA wird erstmal jede Art von Konvertierung ausgeschaltet. Wichtig z.B. auch bei Verschlüsselungen. Dies entspricht CODEPAGE 0.
Dan kommt es darauf an, wie die Datenbank eingerichtet ist und mit welchen Clients gearbeitet wird. Um den Konvertierungsaufwand möglichst gering zu halten, sollte die Datenbank die Codepage des größten End-User-Aufkommens darstellen. Wir haben das mal mit einem AIX-Server (en_us) und Win-Clients (DE 1252) so gemacht.
Wie sieht’s denn gerade aus? Einfach mal den Command "db2 -a connect to db deine-db" vom Client absetzen und die Infos hier mal präsentieren – dann sehen wir weiter.  😎
Viele Grüße
Gernot
30. April 2009 um 6:42 Uhr #4330
AnonymInaktivHallo Gernot,
Danke für Deine Antwort und den unermüdlichen Einsatz gegen die DB2-Ignoranz.  😉
Die Ausgabe des von Dir gewünschten Befehls ist:
 Database Connection Information
Database server     = DB2/LINUXX8664 9.1.4
SQL authorization ID Â = XXXXX
Local database alias  = YYYYYSQLCA Information
sqlcaid : SQLCA Â Â sqlcabc: 136 Â sqlcode: 0 Â sqlerrml: 56
sqlerrmc: 49ÿ1208ÿDB2FO  ÿXXXXXÿQDB2/LINUXX8664ÿ234ÿ234ÿ0ÿ819ÿ0ÿ
sqlerrp : SQL09014
sqlerrd : (1) 2 Â Â Â Â Â Â Â Â (2) -1 Â Â Â Â Â Â Â (3) 0
     (4) 1         (5) 0         (6) 0
sqlwarn : (1) Â Â Â (2) Â Â Â (3) Â Â Â (4) Â Â Â Â (5) Â Â Â (6)
     (7)    (8)    (9)    (10)    (11)
sqlstate: 00000Man beachte die ÿ-Zeichen in der Ausgabe… :-/
Nochmal zu meiner Situation und Frage zum Nachvollziehen:
a) Datenbank auf UTF-8
Database territory                    = DE
Database code page                    = 1208
Database code set                    = UTF-8
Database country/region code               = 49b) Tabelle
c reate table test ( inhalt varchar(3000) for bit data )c) db2 "i nsert into test values (‚äää…äää‘)"  ,wobei der String ‚ä‘ x 3000
d) Terminal steht auf LANG=OSI.o1695469916rue@E1695469916I_ne1695469916-8859-15
e) Bekomme Fehlermeldung, dass String nicht in die Spalte passt.
So, nun, welcher Baustein zum Verständis fehlt mir nun?
Wie wird Client-seitig bestimmt, welcher Ausgangscharacter-Set vorliegt? Warum wird überhaupt ein Characterset in Betracht gezogen, wenn angeblich "FOR BIT DATA" alles abschalten sollte?
Wo fehlt mir den entscheidende Punkt?Gruß
AndreasP.S.: Bin gerade auch über den 403-Fehler gestolpert. Sehr ärgerlich.
7. Mai 2009 um 9:43 Uhr #4420
AnonymInaktivHallo Andreas,
ich denke es sind ganz andere Dinge, die Dir das Problem bescheren.
Erstmal zurück zur Frage: Wo wird überhaupt konvertiert …
Hier beispielhaft verschiedene Zugriffe auf ein DB2 for AIX. Mit "db2 -a connect to MYDB" kommt folgendes Ergebnis (die seltsamen Sonderzeichen ersetzt durch "|"):
Connect am Win/XP Client:
49|1208|MYUSER |MYDB|QDB2/AIX64|442|442|0|1252|1Local Connect am AIX Server:
49|1208|MYUSER |MYDB|QDB2/AIX64|436|436|0|819|1|Die Datenbank MYDB ist wie folgt konfiguriert:
Datenbank Konfiguration (DB CFG):
Database territory = de
Database code page = 1208
Database code set = utf-8
Database country/region code = 49Das "db2 -a" liefert vorneweg Server-Codepage, dann Client-Codepage-Informationen.
- Erster Verweis: Server-Einstellungen = 1208 = Unicode UTF-8, Region 49 = Deutschland
- Zweiter Verweis: Client Einstellungen = 819 = Unix/Derivat, oder 1252 = Windows
Zwischen diesen unterschiedlichen Codepages muss also "vermittelt, d.h. konvertiert werden.
When code page conversion occurs: http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.apdv.sql.doc/doc/c0006849.htm
Unterstützte Gebietscodes und Codepages: http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.admin.doc/doc/r0004565.htm
Die Codepage Konvertierung sollte also wie gewünscht funktionieren, wenn sich alle Endgeräte korrekt deklariert haben.
Nun zum anderen Theme FOR BIT DATA
FOR BIT DATA wird wie CODEPAGE 0 behandelt, also niemals konvertiert. Problematisch könnte sein, wenn Daten mehrfach zwischen Columns mit verschiedenen Spaltenattributen hin und hergeschoben werden.
Wie die Spalten "codiert" sind, kannst Du im Catalog abfragen:
FOR BIT DATA-Spalten tragen das Attribut CODEPAGE=0, siehe Abfrage:s-elect colname, typename, codepage
from syscat.columns
where tabname = ‚yourtable‘Dann zu beachten:
The IBM DB2 Driver for JDBC and SQLJ returns data from a ResultSet.getString call for a CHAR FOR BIT DATA or VARCHAR FOR BIT DATA column as a lowercase hexadecimal string.
Wie kannst man solche Spalteninhalte von [VAR]CHAR FOR BIT DATA Tabellenspalten dann wieder anzeigen:
S-ELECT CAST(COL_FOR_BIT_DATA AS [VAR]CHAR(20) FOR SBCS DATA) FROM YOURTABLEIch hoffe, dass die Infos nützlich sind. Über ein Feedback würde wir uns freuen. Vielleicht hast Du die Lösung ja auch schon gefunden.
Gruß
Gernot
-
AuthorPosts
You must be logged in to reply to this topic.
