Discussion :

[xss.xas]

Bonjour,

Je suis étonné de n'avoir trouvé aucun sujet à ce propos sur developpez.net, et encore plus sur google (suis-je le seul à avoir rencontré ce problème ? les résultats de mes recherches sur google me laissent le penser ...).

Lorsque j'insère le caractère € dans ma table, et que je le ressors (INSERT INTO .... suivi d'un SELECT), je ne retrouve pas un € mais un ? (ou un carré).

Mieux: sur une de mes tables en particulier, si j'utilise un Statement ordinaire, l'euro est modifié, mais si j'utilise un PreparedStatement avec un setString pour insérer mon € dans ma requête, l'euro est inséré correctement ! (sur mes autres tables je suis dans les choux quand-même). En quoi ces 2 méthodes diffèrent-elles ?

Mon administrateur DB2 est frileux, et ne souhaite pas se risquer à modifier les tables de transcodage (les tables sont d'après lui toutes en EBCDIC, mais il n'a pas précisé quelle "version" d'EBCDIC -car parait-il qu'il y en a eu un certain nombre ...).

La question suivante en découle :
- A quel niveau est défini un charset ? Table ? Tablespace ? Schema ? Base de données toute entière (là je suis cuit) ? Système (et là encore plus) ?

J'aimerais simplement avoir des tables capables de recevoir proprement n'importe quel caractère, mais apparement ca a l'air plus compliqué que de simplement tout sauvegarder, dropper et recréer la table avec un charset différent (dont les tables de transcodage sont à jour). Il existe même un charset UTF-EBCDIC (http://fr.wikipedia.org/wiki/UTF-EBCDIC), si vraiment il faut garder du tout-EBCDIC.

Si quelqu'un a un tuyeau pour moi je suis preneur (je suis même étonné que depuis 5 ans d'existence de l'€uro, personne ne se soit soucié du problème ... -dans mon entreprise çela va de soi ^^).

(Je précise que sur mon DB2 v8.2 sur windows, les tables sont en IBM-1252, et que je n'ai aucun problème avec).

[gregory.broissard]

Il faudrait savoir quel EBCDIC.

Le Francais standard IBM-297 ne gere pas l'euro. Par contre le 1147 qui est une copie exacte du 297 le gère. Le 1147 va te permettre de stocker tous les caractères européens latins.

Le seul moyen de pouvoir stocker sans pb tous les caractères (chinois, russe, etc...) est d'utiliser de l'unicode : UTF-8 par exemple.
Cependant une étude doit être menée pour évaluer l'impact sur les données et sur la taille de la base si tu as bcp de libellés.

Pour voir dans quel codepage ton TS se trouve:
SELECT NAME,SBCS_CCSID FROM SYSIBM.SYSTABLESPACE
WHERE DBNAME='database'
AND NAME='nomts';

Pour transcoder un TS, un simple alter tablespace suffit.Attention. Pour transcoder un tablespace et le passer par exemple du 297 au 1147, il faut que les codepages soient installés au niveau z/OS.

[xss.xas]

Merci grégory, tu me rassures beaucoup là

Mon DBA m'avait parlé d'effets de bord avec d'autres applicatifs etc ... je ne voyais vraiment pas pourquoi, puisque mon application web est la seule à accéder à ces tables, et qu'ils créent un tablespace par table. Chaque table est donc isolée, et je pourrais même avoir une table en latin-1 et une autre table en UTF-8 dans la même appli, sans voir de bizarreries, en principe ... Mais bon, si je peux avoir toutes mes tables en IBM-1147 moi je dis amen =)

Cependant, le point qui m'a interpellé le plus, c'est à propos de la différence de comportement entre un Statement et un PreparedStatement+setString() (le PreparedStatement sans utiliser les ? et setString() se comporte comme un Statement ordinaire).

Qu'est ce que cette fonction setString() peut bien faire qui permette à l'euro de rentrer correctement dans une table (codé 0x9F) où un Statement le transforme en 0x3F ? Ou plutôt, qu'est ce qu'une requête simple (sans setString()) ne fait pas avant d'envoyer les caractères vers DB2 ? C'est étonnant ! Mais bon, je pense que le simple fait d'alter le tablespace suffira a régler mon problème pour de bon

Merci beaucoup pour ton aide !

J'te paye un café ? :p

[edit: je marquerais ce thread comme résolu dans le courant de la semaine prochaine quand j'aurais réussi à régler le problème au travail, on ne sait jamais, si je rencontre des mauvaises surprises ... je reviendrais les poster ici pour la postérité ]

[xss.xas]

Bon, je peux dores et déjà confirmer que toutes les tables sur le système sont en Cp297 (merci grégory ^^). Ca confirme nos soupçons.

En revanche je galère pour trouver comment faire la conversion avec ALTER TABLESPACE ... qqn aurait un exemple ? La doc que j'ai n'a pas l'air d'en faire mention

[Luc Orient]

...
En revanche je galère pour trouver comment faire la conversion avec ALTER TABLESPACE ... qqn aurait un exemple ? La doc que j'ai n'a pas l'air d'en faire mention

ALTER TABLESPACE ... CCSID ...
peut être ..
ALTER TABLESPACE

Voir aussi cette note :
Note

Par contre j'utiliserais tout cela avec une extrême prudence ... gare aux effets de bord ...

[xss.xas]

Merci Luc,

Hmm compte tenu de la simplicité de la manipulation (ALTER TABLESPACE monTS CCSID 1147), je mesure mal les implications de celle-ci ...

Tout ce dont on parle, c'est de rajouter un code "clairement défini" pour le caractère € ? Après tout, c'est la seul différence entre du IBM-297 et du IBM-1147 si je ne m'abuse ?

Sachant que ces tables ne sont accédées qu'à partir de mon appli web (et aucune autre appli de l'entreprise), je vois mal quel effet de bord "fonctionnel" il pourrait y avoir. Du point de vue administration système peut-être ? Seul mon DBA pourra me confirmer les soucis que ca lui causerait (batchs, sauvegardes, etc...), mais il n'a pas l'air très bavard sur la question

Merci pour vos lumières en tout cas

[xss.xas]

En grattant encore un peu je suis tombé sur ça: http://publib.boulder.ibm.com/infoce...t/euro9217.htm ... où il est dit qu'il faut modifier la totalité de la base de données d'un seul coup, sous peine de risquer de la corruption de données, ou d'avoir des résultats "imprévisibles" ... et vous savez quoi ? Je trouve ca grossièrement tiré par les cheveux

A tout hazard, quelqu'un a-t-il déjà eu à faire cette manipulation (sur un tablespace seul ou sur toute une base) ?

Pourquoi faut-il toujours que ce soit compliqué ?

[xss.xas]

Je mets ici un pm que j'ai recu de Dell74 à ce sujet, ainsi que ma réponse :
-----------------------------------------------------------------------

Bonjour,
pour ce qui est de l'euro (entre autre)
DB2 sur Z/OS (en local) n'effectue pas de conversion sur un INSERT, on va donc stocker la valeur que l'on saisie.
l'euro sur un code page 1147 est a X'9F'.
le select va rendre la meme valeur. il faut s'assurer que l'emulateur qui restitue l'information est bien avec le meme code page.
DB2 effectue une conversion lorsque l'on travaille en DRDA. on va utiliser alors le CCSID du db2, et la ca peut se compliquer.

Malheureusement je ne suis pas en local, je fais tous mes tests via JDBC, et surtout, toutes mes tables sont en Cp297. Du coup, quand je fais un INSERT avec un €, ce € n'est pas transformé en X'9F' comme je l'attends, mais en X'3F'. Quand je refais un SELECT, ce n'est pas un € qui sort, mais un ? (le point d'interrogation).

Idéalement, il faudrait simplement que mes tables soient converties en Cp1147 pour qu'elles puissent avoir connaissance du caractère € et qu'il soit inséré proprement en tant que X'9F'. Je précise que je n'ai pas ce problème de conversion sur une autre instance de DB2 dont les tables sont en IBM-1252/Cp1252.

La nature du problème me parait évidente : Cp297 ne gère pas l'euro (et toutes les docs concordent sur ce point). Merci pour l'info concernant les requêtes en local cependant, ca m'a aidé à comprendre une partie du problème.