Discussion :

[ljoly]

Bonjour,

je migre un base 8.1.7.4 en WE8ISO8859P1 vers une base 9.2.0.8 en UTF8. je fais un export des schémas sur la base source puis un import sur la base cible. j'ai un problème car les caractéres spéciaux (accents...) sont codés sur 2 caractères en UTF8 au lieu de 1 en WE8ISO. Cela provoque des depassements de taille de colonnes et le message suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
IMP-00019: row rejected due to ORACLE error 1401
IMP-00003: ORACLE error 1401 encountered
ORA-01401: inserted value too large for column

Je n'ai pas la possibilité de modifier le format des tables.
Quelqu'un a t'il déjà rencontré ce type de problème?

[LeoAnderson]

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

[ljoly]

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

Je n'ai pas la possibilité de créer les tables car il s'agit d'un migration oracle application 11.0.3 vers oracle e-business 11.5.10. Le shema de données sur la base cible est créé par l'installation standard (rapidwiz).

[LeoAnderson]

si vous faites un import qui créé les tables, je ne vois pas en quoi vous ne pouvez pas créer les tables à la main ?!

[ljoly]

oui, c'est une classique.
vous devez créer les tables avec le NLS_LENGTH_SEMANTICS correctement positionné (i.e. CHAR) ou spécifier CHAR dans la définition des colonnes VARCHAR2 puis, ensuite, importer le dump IGNORE=Y ROWS=Y

C'est lié à la structure UTF
Téléphones= 10 caractères = 10 bytes en ISO, 12 en UTF
et l'import garde la même structure VARCHAR2(10 BYTES) => VARCHAR2(10 BYTES), et ce quelque soit le NLS_LENGTH_SEMANTICS

[EDIT]
le plus simple et le plus propre serait sûrement de migrer la base de 8i en 9i (par upgrade) puis ensuite, de changer le CS
[/EDIT]

Je viens d'essayer, ça ne fonctionne pas, j'ai le même message d'erreur.

[ljoly]

En effectuant la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter database character set internal_use UTF8;

sur la base 8.1.7.4 en WE8ISO8859P1, puis en faisant un export et un import sur la base cible, ça fonctionne et je retrouve tous mes caractères spéciaux. Ca parait un peu simple?

[LeoAnderson]

Allez-y ! essayez tout et ensuite, à nous de réfléchir ?

je vous avais conseillé de créer les tables, pas de les importer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE ...

[ljoly]

Allez-y ! essayez tout et ensuite, à nous de réfléchir ?

je vous avais conseillé de créer les tables, pas de les importer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE ...

il s'agit d'une base e-business 8, càd plusieurs centaines de tables, ça serait trop long à recréer les tables une par une.

[ljoly]

En effectuant la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter database character set internal_use UTF8;

sur la base 8.1.7.4 en WE8ISO8859P1, puis en faisant un export et un import sur la base cible, ça fonctionne et je retrouve tous mes caractères spéciaux. Ca parait un peu simple?

Qui peut me dire ce que fait exactement le alter database?
Dans metalink on me conseille d'effectuer également un csscan avant, A quoi ça sert? ça génére juste un report avec les lignes non convertibles ou tronqués?

[pifor]

Les commandes ALTER DATABASE SET CHARACTER USE ou ALTER DATABASE SET CHARACTER INTERNAL_USE ne font pas de conversion des colonnes contenant des caractères mais change le jeu de caractères déclaré de la base d'après la note Metalink 66320.1.

CSSCAN permet de vérifier que les données existantes seront bien reconnues dans le nouveau jeu de caractères: il ne doit signaler que des données ChangeLess sinon il y aura incohérence entre le jeu de caractères déclaré de la base et les données de la base

[louping]

Bonjour,

je migre un base 8.1.7.4 en WE8ISO8859P1 vers une base 9.2.0.8 en UTF8.

Il me semble que UTF8 est inclus dans WE8ISO8859P1, et s'il y a des caractères au dela de UTF8, ca va être chaud...
Le mieux c'est de faire croire que c'est la même police afin qu'Oracle ne fasse pas de convertion.
Et là je sais plus mais mettre le NLS_LANG à UTF8 à l'export ??
Sinon, je me souviens qu'on avait trifouillé l'entête de l'export pour faire croire à l'import que c'est de l'UTF8...(script en C pour changer le premier mot)
A+

[LeoAnderson]

Il me semble que UTF8 est inclus dans WE8ISO8859P1

Non.

L'UTF est un unicode => il peut stocker tous les caractères, y compris le martien du sud, si nécessaire mais cela implique que la longueur d'encodage est variable

les WE8ISO... sont des jeux 8 bits iso-longueurs d'encodage => 256 caractères max. En plus, pour les WE, on n'a retenu que les caractères de l'europe de l'ouest. Les caractères des pays baltes n'y sont pas par exemple.

je me souviens qu'on avait trifouillé l'entête de l'export pour faire croire à l'import que c'est de l'UTF8

ben voyons...
en UTF, le 1er bit de l'octet indique ou non la présence d'un octet suivant... donc on ne peut pas "faire croire", sauf à prendre de gros risques...

il suffit de positionner le NLS_LANG sur l'OS...

[pifor]

Il me semble que UTF8 est inclus dans WE8ISO8859P1

Non, c'est l'inverse d'après le Globalization Guide.

Le mieux c'est de faire croire que c'est la même police afin qu'Oracle ne fasse pas de convertion.

Cela dépend: voir la FAQ OTN NLS_LANG à ce sujet par exemple.

Sinon, je me souviens qu'on avait trifouillé l'entête de l'export pour faire croire à l'import que c'est de l'UTF8...(script en C pour changer le premier mot)

Le format du fichier export n'est pas documenté et modifier directement un fichier export n'est pas supporté

[louping]

Les Oracles ont parlé,

Note 260192.1 Changing WE8ISO8859P1/ WE8ISO8859P15 or WE8MSWIN1252 to UTF8 with ALTER DATABASE CHARACTERSET

You can't simply use "ALTER DATABASE CHARACTER SET" to go from WE8ISO8859P1 or WE8ISO8859P15 or WE8MSWIN1252 to (AL32)UTF8 because (AL32)UTF8 is not a binary superset of any of these character sets.

[LeoAnderson]

Oui, c'est exactement ce qu'on disait : you can't !

Après, ne pas confondre "superset" et "caractères gérés".

Un superset, c'est un jeu plus complet mais dont les codes des caractères communs sont identiques (par exemple WE8ISO8859P1 et WE8ISO8859P15)

la liste des caractères gérés peut être commune à 90% mais si les caractères communs n'ont pas le même codage, on dit qu'ils n'ont pas le même superset et cela complique les procédure de migration, mais cela n'influe pas (trop) sur les communications Client/Serveur