Discussion :

[kooky]

Bonjour,

J'obtiens une erreur d'import sur le chargement d'un fichier sur une base Oracle 10g XE alors que cela fonctionne sur une base 11.g
Pour information, voici le paramétrage de ma base 10gXE

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
	NLS_LANGUAGE	AMERICAN
	NLS_TERRITORY	AMERICA
	NLS_CURRENCY	$
	NLS_ISO_CURRENCY	AMERICA
	NLS_NUMERIC_CHARACTERS	.,
	NLS_CHARACTERSET	AL32UTF8
	NLS_CALENDAR	GREGORIAN
	NLS_DATE_FORMAT	DD-MON-RR
	NLS_DATE_LANGUAGE	AMERICAN
	NLS_SORT	BINARY
	NLS_TIME_FORMAT	HH.MI.SSXFF AM
	NLS_TIMESTAMP_FORMAT	DD-MON-RR HH.MI.SSXFF AM
	NLS_TIME_TZ_FORMAT	HH.MI.SSXFF AM TZR
	NLS_TIMESTAMP_TZ_FORMAT	DD-MON-RR HH.MI.SSXFF AM TZR
	NLS_DUAL_CURRENCY	$
	NLS_COMP	BINARY
	NLS_LENGTH_SEMANTICS	BYTE
	NLS_NCHAR_CONV_EXCP	FALSE
	NLS_NCHAR_CHARACTERSET	AL16UTF16
	NLS_RDBMS_VERSION	10.2.0.1.0

et le paramétrage de ma base 11g

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
	NLS_LANGUAGE	AMERICAN
	NLS_TERRITORY	AMERICA
	NLS_CURRENCY	$
	NLS_ISO_CURRENCY	AMERICA
	NLS_NUMERIC_CHARACTERS	.,
	NLS_CHARACTERSET	WE8MSWIN1252
	NLS_CALENDAR	GREGORIAN
	NLS_DATE_FORMAT	DD-MON-RR
	NLS_DATE_LANGUAGE	AMERICAN
	NLS_SORT	BINARY
	NLS_TIME_FORMAT	HH.MI.SSXFF AM
	NLS_TIMESTAMP_FORMAT	DD-MON-RR HH.MI.SSXFF AM
	NLS_TIME_TZ_FORMAT	HH.MI.SSXFF AM TZR
	NLS_TIMESTAMP_TZ_FORMAT	DD-MON-RR HH.MI.SSXFF AM TZR
	NLS_DUAL_CURRENCY	$
	NLS_COMP	BINARY
	NLS_LENGTH_SEMANTICS	BYTE
	NLS_NCHAR_CONV_EXCP	FALSE
	NLS_NCHAR_CHARACTERSET	AL16UTF16
	NLS_RDBMS_VERSION	11.1.0.7.0

La seule différence se trouve au niveau du CHARACTERSET.

Mon fichier de contrôle est le suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
LOAD DATA
INFILE 'C:\ARTLIB.txt'
TRUNCATE
INTO TABLE ARTLIB
FIELDS TERMINATED BY "|"
(ARTID CHAR(7),
ARTLIB1 CHAR(255),
ARTAILLE1 CHAR(255),
ARTAILLE2 CHAR(255),
ARTLIB2 CHAR(255))

Le chargement en Oracle 11g fonctionne sans erreur et les accents sont importés correctement.
Le chargement en Oracle 10g XE me renvoie l'erreur suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
   Nom de colonne               Position   Long.  Séparat. Encadrem. Type de données
------------------------------ ---------- ----- ---- ---- ---------------------
ARTIDCIO                            FIRST     7   |       CHARACTER            
ARTLIB1                              NEXT   255   |       CHARACTER            
ARTAILLE1                            NEXT   255   |       CHARACTER            
ARTAILLE2                            NEXT   255   |       CHARACTER            
ARTLIB2                              NEXT   255   |       CHARACTER            
 
Enregistrement 24036 : Rejeté - Erreur sur table ARTLIB, colonne ARTLIB1.
ORA-12899: valeur trop grande pour la colonne ARTLIB1 (réelle : 258, maximum : 255)

Pourtant la ligne en erreur sur l'import sur la colonne ARTLIB1 contient 253 caractères. J'ai vu que les accents passaient sur 2 bytes d'où le dépassement des 255 caractères.
J'ai donc essayé d'ajouter à la 2ème ligne du fichier de contrôle CHARACTERSET WE8MSWIN2152 pour prendre en compte le même jeu de caractère que la base 11g, mais rien n'y fait, j'ai toujours la même erreur.

Quelqu'un aurait une solution?
D'avance merci.

[Scriuiw]

Quel est le jeu de caractères du fichier ?

Avez-vous essayé de tronquer les colonnes afin de forcer une taille maxi et voir le résultat final ?

[Mohamed.Houri]

Bonjour,

Quelqu'un aurait une solution?
D'avance merci.

Je pense que vous devriez bien préciser le ''character set'' de votre fichier de données dans le ''control file''

https://forums.oracle.com/forums/mes...17844#10117844

[kooky]

Merci pour vos réponses mais en fait ça fait longtemps que j'ai trouvé la solution mais il est vrai que j'ai un peu oublié ce topic.

Pour apporter une réponse à mon "ancien" problème, cela venait de ma base 10 XE qui était en Unicode alors que ma base 11g était en ANSI.
En unicode les caractères accentués sont codés sur 2 bits alors qu'en ANSI ils le sont sur 1. D'où l'origine de mes colonnes trop courtes.
J'ai donc modifié mon script de création de table pour forcer la création des colonnes susceptibles d'accueillir des caractères accentués avec l'option CHAR (au lieu de BYTE par défaut).

Voilou, le topic est donc résolu.

[Mohamed.Houri]

Bonjour,

Je suis désolé de ne pas avoir fait bien attention à toutes les informations que vous avez postées dans votre première intervention. La réponse s'y trouvait déjà. Mais parfois on embarque sur des propositions sans vraiment prendre le temps nécessaire pour l'analyse.

Code :

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

1
2
3
4
5
6
 
10g
NLS_CHARACTERSET AL32UTF8 
 
11g
NLS_CHARACTERSET WE8MSWIN1252

Je pense donc que vous êtes en train de passer d'un mode ''single-byte-characterset" WE8MSWIN1252 vers un mode "multi-byte characterset" (AL32UTF8). Ce qui veut dire qu'1 caractère peut prendre jusqu'à 4 bytes.

Si vous aviez des colonnes définies comme varchar2(36 bytes) en "single-byte-characterset" , elles peuvent subitement devenir trop petites en mode "multi-byte characterset" qui peut aller dans ce cas jusqu'à 36 x 4 = 144 bytes

Donc, effectivement, il est préférable de definir votre colonne comme

Code :

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

  varchar2 (36 char)

plutôt qu'en

Code :

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

 varchar2(144 bytes)

Mais attention, il me semble que vous vous êtes concentré uniquement sur les colonnes qui vous posent problème aujourd'hui. Vous devriez peut-être vous prémunir contre d'autres colonnes en ajustant correctement leur type si bien qu'il convienne à votre nouveau mode de caractère

[kooky]

Non, j'ai bien anticipé la chose sur les colonnes VARCHAR2
Cela fait plus d'un an que cela tourne sans erreur.

Le sujet étant résolu, cela pourra aider d'autres personnes.