UTF-8 problème de semantic

Version imprimable

03/05/2006, 10h09
yolepro

UTF-8 problème de semantic

Bonjour,

Comme demandé ici http://www.developpez.net/forums/showthread.php?t=77831

J'ouvre une nouvelle discussion pour peut etre développer un peu plus la problématique UTF-8.

Mon problème. J'ai une base en ISO-8859-1 (correspondance Oracle WE8ISO8859P15). Nous utilisons des VARCHAR2 partout et de temps en temps des VARCHAR2(4000) sans jamais spécifier le type semantic (CHAR ou BYTE).

Nous devons migrer cette base en UTF-8 (ou peut etre AL32UTF8 je ne vois pas trop la différence), mais je ne sais pas trop comment s'y prendre ni quels sont les impacts (ce n'est pas moi qui fait la migration mais un DBA).

Nous arrivont a changer les parametres dans le fichier d'init pour que la base passe en NLS_LENGTH_SEMANTICS = CHAR

Mais malgrés cela le schema de ma base (quand PL/SQL je vais dans Reports / DBA / NLS Database parameter) NLS_LENGTH_SEMANTICS reste à BYTE.

Est ce normal?

Dans tous les cas, comment faire pour pouvoir faire passer 4000 caractères dans un VARCHAR2 en UFT-8.

Dois-je redéfinir le champs en CLOB?
Cela est il problématique pour mes autres champs (ex VARCHAR2(10) )?

Merci d'avance pour vos réponses.
03/05/2006, 10h45
SheikYerbouti

Pourquoi pas simplement :

Code:

VARCHAR2(4000 CHAR)
03/05/2006, 10h55
yolepro

Effectivement (j'ai testé) si je créé une autre table en forceant tous les champs a CHAR ex VARCHAR2(10 CHAR). Il n'y a plus de problème.

Mais je suis donc obligé de changer tout mon script de création de base (et c'est pas vraiment ce que je veux faire).
03/05/2006, 11h12
SheikYerbouti

Il existe des procédure de migration strictes et détailées. Vous (ou votre DBA) devez vous les procurer sur Metalink, Notament.
03/05/2006, 11h43
LeoAnderson

Non, vous n'avez pas le choix : vous devez modifier une à une toutes les tables pour lesquelles vous souhaitez passer de BYTES à CHAR.

Le NLS_LENGHTH_SEMANTICS ne sert que pour les tables qui sont créés sans spécifier (et les procédures d'import spécifient); cela n'impacte pas les tables déjà créées.

Mais si vous faites une modification de NLS_LENGTH_SEMANTICS dans le init.ora, vous êtes obligé de redémarrer la base... ;-)

Bonjour,

Je réponds tard mais je suis toujours bloqué avec ce problème.

J'ai fait un autre test depuis la dernière fois.

En créant une table basique sans forcer les champs VARCHAR2:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 -- Create table create table T_TESTCHAR ( CODE_TEST INTEGER not null, LBL_TEST VARCHAR2(10) not null, LBL_TEST_EN VARCHAR2(10) ) tablespace DATA_M_ARP pctfree 10 initrans 1 maxtrans 255 storage ( initial 64K minextents 1 maxextents unlimited );
Et la, je peux effectivement insérer 10 caractère UTF-8.

Donc je me demande pourquoi il n'est pas possible de faire un export de la structure de l'ancienne base (la base sans les données) comme ca j'ai mes tables non typées. Ensuite faire une autre instance de base vide avec les paramètre SEMANTICS à CHAR et lancer le script de creation de base.

Enfin migrer les données de l'ancienne base sur la nouvelle.

Cas vous choque ?

23/05/2006, 20h56
pifor

Citation:

Et la, je peux effectivement insérer 10 caractère UTF-8

Attention, cela peut dépendre des caractères insérés: le nombre d'octets utilisé peut être variable ... Pour afficher la représentation binaire d'un châine de caractères stockée dans la base, utilisez:

Code:

SELECT DUMP(lbl_test) FROM t_testchar;

Citation:

Donc je me demande pourquoi il n'est pas possible de faire un export de la structure de l'ancienne base (la base sans les données) comme ca j'ai mes tables non typées. Ensuite faire une autre instance de base vide avec les paramètre SEMANTICS à CHAR et lancer le script de creation de base.

Enfin migrer les données de l'ancienne base sur la nouvelle.

Il faut tester cette possibilité. Faites attention au paramètre de NLS_LANG lorsque vous faites l'export car une conversion peut déjà être effectuée à l'export.