[SQL] charger données russes dans une BDD existante

**lolotte35** · 14/06/2006, 10h40

Bonjour,

J'ai une base de données Oracle 8.1.7 qui contient des données de différents pays tel que la France, l'espagne, la belgique....

On me demande d'insérer des données russes qui sont encodées en CP1251.
Je peux convertir ces données en unicode si je le souhaite mais je ne sais pas du tout comment charger ces données dans la base.
Le chargement se fait en sql loader , ma ligne de commande est :

Code :

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

sqlldr dbadwh/dbadwh@dwh source/RUS_CHR_TIE_GAR_1.ctl data=../data/RUSGARAN_UTF8.DAT

En effet, si je charge les données directement sans transformer le fichier de données (donc les données sont en CP1251), le chargment se passe bien mais les caractères syrillic ne sont pas lisibles.

Il faut donc que je transforme le fichier en UTF8, les caractères sont corrects nsi je regarde le fichier de données mais le chargement ne passe pas bien,

voici le message d'erreur :

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
SQL*Loader: Release 8.1.7.0.0 - Production on Me Jun 14 10:34:16 2006
 
(c) Copyright 2000 Oracle Corporation.  All rights reserved.
 
Fichier de contrôle :   source/RUS_CHR_TIE_GAR_1.ctl
Fichier de données :      ../data/RUSGARAN_UTF8.DAT
  Fichier défectueux :     source/RUSGARAN_UTF8.bad
  Fichier de rebut :  aucune spécification
 
 (Allouer tous les rebuts)
 
Nombre à charger : ALL
Nombre à sauter: 0
Erreurs permises: 50
Tableau de liens :     64 lignes, maximum de 65536 octets
Continuation :    aucune spécification
Chemin utilisé:      Classique
 
Table TMP_TIE_GAR, chargé à partir de chaque enregistrement physique.
Option d'insertion en vigueur pour cette table : APPEND
 
   Nom de colonne               Position   Long.  Séparat. Encadrem. Type de données
------------------------------ ---------- ----- ---- ---- ---------------------
CODE_PAYS                                                 CONSTANT
    La valeur est 'RUS'
FLAG_CREATION                                             CONSTANT
    La valeur est 'N'
FLAG_MODIF                                                CONSTANT
    La valeur est 'N'
ADRESSE                              1:40    40           CHARACTER            
TIERS_CLIENT                        41:51    11           CHARACTER            
CODE_POSTAL                         85:90     6           CHARACTER            
VILLE                              98:137    40           CHARACTER            
NOM                               251:290    40           CHARACTER            
 
Enregistrement 1 : Rejeté - Erreur sur table TMP_TIE_GAR, colonne TIERS_CLIENT.
ORA-01722: Nombre non valide

et il dit "nombre non valide" pour tous les enregistrements.

Auriez vous une solution?

Merci

Charlotte,

Boulogne (92)

**annickl** · 15/06/2006, 02h15

Table TMP_TIE_GAR, chargé à partir de chaque enregistrement physique.
Option d'insertion en vigueur pour cette table : APPEND

Nom de colonne Position Long. Séparat. Encadrem. Type de données
------------------------------ ---------- ----- ---- ---- ---------------------
CODE_PAYS CONSTANT
La valeur est 'RUS'
FLAG_CREATION CONSTANT
La valeur est 'N'
FLAG_MODIF CONSTANT
La valeur est 'N'
ADRESSE 1:40 40 CHARACTER
TIERS_CLIENT 41:51 11 CHARACTER
CODE_POSTAL 85:90 6 CHARACTER
VILLE 98:137 40 CHARACTER
NOM 251:290 40 CHARACTER

Enregistrement 1 : Rejeté - Erreur sur table TMP_TIE_GAR, colonne TIERS_CLIENT.
ORA-01722: Nombre non valide

Question peut-être idiote, mais as-tu pu vérifier les formats des champs TIERS_CLIENT et CODE_POSTAL une fois converti en UFT8, ceux de la table d'accueil?

**lolotte35** · 15/06/2006, 08h59

La table d'accueil est identique à celle des autres pays, aucun changement n'a été fait.

voilà le script de la table:

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
21
22
23
24
 
CREATE TABLE TMP_TIE_GAR ( 
  TIERS_CLIENT   NUMBER (11), 
  CODE_PAYS      VARCHAR2 (4), 
  CODE_POSTAL    VARCHAR2 (6), 
  ADRESSE        VARCHAR2 (40), 
  FLAG_CREATION  CHAR (1), 
  FLAG_MODIF     CHAR (1), 
  NOM            VARCHAR2 (40), 
  VILLE          VARCHAR2 (40), 
  NO_TELEPHONE   NUMBER (10))
   TABLESPACE TPB_D NOLOGGING 
   PCTFREE 10
   PCTUSED 40
   INITRANS 1
   MAXTRANS 255
  STORAGE ( 
   INITIAL 104857600
   NEXT 20971520
   PCTINCREASE 0
   MINEXTENTS 1
   MAXEXTENTS 2147483645
   FREELISTS 1 FREELIST GROUPS 1 )
   NOCACHE;

**annickl** · 15/06/2006, 15h21

Excuse-moi, je voulais dire "vérifier le format des données contenues dans les champs, après conversion UFT8". Sinon, je ne vois pas...

**lolotte35** · 15/06/2006, 15h32

tu vérifierais ça comment?
Quand j'ouvre le fichier texte de données, je vois des chiffres.....

Je te joins mon fichier de données converti.
Peut être verras tu quelque chose qui m'aurait échapper.

**annickl** · 15/06/2006, 16h45

Sur ce type d'erreur, je vérifie habituellement de façon "fonctionnelle" :
- vérifier la longueur de chaque enregistrement,
- vérifier que les données sont à la bonne place dans le fichier d'entrée (exemple : toutes les plages d'adresse sont alignées? )
- vérifier qu'il n'y a pas de caractère polluant....

Le fichier joint, rusgaran_UFT8.txt ne répond pas à ces critères. Il y a effectivement des caractères cyrilliques, les données ne sont pas alignées, il semble que des enregistrements russes soient mélangés avec des enregistrements français....

Bien que ne connaissant pas SQL Loader (et notamment je m'interrogeais sur la syntaxe "CHARACTER" pour récupérer des données "NUMBER") , le problème semble se situer sur la structure de ce fichier converti....

**lolotte35** · 15/06/2006, 17h34

non en fait il y avait 4 lignes de décalées de 4 caractères car il y avait des null dans le fichier d'origines.
Mais cela ne devrait pas faire raté le chargement des lignes situées avant.

Il y a des données française et russe car c'est fichier test.

Bon je viens de changer mon fichier de Unicode à UTF8, c'est mieux il charge les données mais à la lecture ça ressemble àrien du tout....

N'y a-t-il pas un paramètre dans la base à changer pour qu'il comprenne l'UTF8 ?

**annickl** · 16/06/2006, 02h58

C'est la première fois que l'opération est faite?

Alors, il y a des actions à faire au niveau de la base Oracle, voir par exemple l'article de SQLPRO sur les jeux de caractère, la fonction Traduction, et les problèmes de collation :

http://sqlpro.developpez.com/cours/s.../?page=partie1

Pour l'utilisation de UFT8, je n'ai pas eu le temps de creuser, mais du coup, je me demande si cela s'impose....

Une question complémentaire à intégrer dans tes reflexions : on ne risque pas de te demander de restituer des informations en cyrillique?

**pifor** · 16/06/2006, 08h50

voir par exemple l'article de SQLPRO sur les jeux de caractère, la fonction Traduction, et les problèmes de collation

Je ne recommanderais pas cet article car il se base essentiellement sur la norme SQL2 et les exemples utilisent uniquement SQL Server

Or les fonctionnalités de support des différents jeux de caractères, environnements locaux, etc. dans Oracle sont assez différents au moins au niveau syntaxique ..

Le document de référence sur le sujet pour Oracle est le Globalization Support Guide: http://download-uk.oracle.com/docs/c...b14225/toc.htm

Pour cette discussion, il faudrait avoir le résultat des requêtes suivantes:

Code :

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

1
2
3
 
SELECT * FROM nls_database_parameters;
SELECT * FROM nls_session_parameters;

et le contenu de la variable d'environnement NLS_LANG dans l'environnement client qui exécute sqlldr; exécutez dans l'outil sqlplus la commande suivante:

Code :

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

 @.[%NLS_LANG%]

**lolotte35** · 16/06/2006, 09h47

Bonjour,

Alors je vous joins les résultats de mes select.
Par contre, lorsque je tape "@.[%NLS_LANG%]" il me dit impossible d'ouvrir le fichier french......

Je ne connais pas du tout cette partie d'Oracle.
Alors je vais sûrement poser une question toute bête... :
Est ce que dans la même base de données peuvent cohabité des données françaises, européenne et des données russes ?
En sachant que les données françaises seront lues en latin1 et que celles russes seront lues en cyrilliques?

Je ne peux pas accéder à http://download-uk.oracle.com/docs/c...b14225/toc.htm, je n'ai pas de login oracle ni de SSO...

Merci

**pifor** · 16/06/2006, 13h27

Par contre, lorsque je tape "@.[%NLS_LANG%]" il me dit impossible d'ouvrir le fichier french......

C'est normal, c'est le contenu complet du message d'erreur qui permet de connaître la valeur de NLS_LANG.

Je ne peux pas accéder à http://download-uk.oracle.com/docs/c...b14225/toc.htm, je n'ai pas de login oracle ni de SSO...

Il suffit d'avoir un login OTN gratuit sans aucune condition d'achat de produit ou service d'Oracle.

Est ce que dans la même base de données peuvent cohabité des données françaises, européenne et des données russes ?
En sachant que les données françaises seront lues en latin1 et que celles russes seront lues en cyrilliques?

Je pense que oui avec les possibilités suivantes pour le jeu de caractères de la base:

CL8ISO8859P5
ISO 8859-5 Latin/Cyrillic

CL8MSWIN1251
MS Windows Code Page 1251 8-bit Latin/Cyrillic

AL32UTF8
Unicode 4.0 UTF-8 Universal character set

Les principe des base étant:

d'avoir comme jeu de caractères de la base un sur-ensemble de tout les jeux de caractères devant être supportés par les différents clients (pour des application multi-langues, Oracle recommende AL32UTF8)
d'avoit côté client la bonne configuration (NLS_LANG) qui va automatiquement faire la traduction entre le jeu de caractères/l'environnement client et les données de la base avec le jeu de caractères de la base de données.

**lolotte35** · 19/06/2006, 09h36

Ok, donc si je résume :

1 - Sur l'oracle du serveur qui contient la BDD, je dois modifier le paramètre :
"NLS_CHARACTERSET=WE8ISO8859P1" en
"NLS_CHARACTERSET=AL32UTF8"

2- Le NLS_LANG du client doit correspondre à sa langue pour qu'il puisse lire ses données.

et il y a une commande pour cela?
Cela n'aura pas d'effet de bord sur le reste des données?
Est ce que je peux toujours charger les données françaises en Latin5?
Et pour les données russes, l'UTF8 fonctionnera si je modifie le paramètre NLS_CHARACTERSET?

**pifor** · 19/06/2006, 11h17

1 - Sur l'oracle du serveur qui contient la BDD, je dois modifier le paramètre :
"NLS_CHARACTERSET=WE8ISO8859P1" en
"NLS_CHARACTERSET=AL32UTF8"

Oui et non. On peut changer le jeu de caractères d'une base de données mais c'est une opération assez lourde (il faut utiliser les outils CSSCAN et le script CSALTER): il vaut peut-être mieux recréer la base.

2- Le NLS_LANG du client doit correspondre à sa langue pour qu'il puisse lire ses données.

et il y a une commande pour cela?

Pas de commande Oracle: positionner NLS_LANG dans le bon script de démarrage suffit.

Cela n'aura pas d'effet de bord sur le reste des données?

Non mais changer le jeu de caractères d'une base peut avoir des conséquences importantes. Des colonnes CHAR et VARCHAR2 peuvent devenir trop petites car un caractère étendu peut occuper plusieurs octets au lieu d'un.

Est ce que je peux toujours charger les données françaises en Latin5?

Oui, avec la bonne valeur de NLS_LANG.

Et pour les données russes, l'UTF8 fonctionnera si je modifie le paramètre NLS_CHARACTERSET?

Je ne l'ai pas testé mais ça doit marcher car AL32UTF8 est un des jeu de caractères le plus complet.

**lolotte35** · 24/07/2006, 16h43

Bonjour,

J'ai réussi à créer ma base de données en UTF8, j'ai mis le character set UTF8 lors de la création.

Maintenant, j'essaye de charger mes données dans la base.
J'utilise ce fichier pour charger en sql loader:

-- Chargement GARAN.DAT

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
LOAD DATA
APPEND
INTO TABLE TMP_TIE_GAR
(
	CODE_PAYS		CONSTANT			"RUS",
	FLAG_CREATION	CONSTANT			"N",
	FLAG_MODIF		CONSTANT			"N",
	ADRESSE			POSITION(1:40)		CHAR,
	TIERS_CLIENT	POSITION(41:51)		Integer EXTERNAL,
	CODE_POSTAL		POSITION(85:90)		CHAR,
	VILLE			POSITION(98:137)	CHAR,
	NOM				POSITION(251:290)	CHAR
)

Je dispose d'un fichier plat.

Si je le charge tel quel, mes caractères russes ne sont pas reconnu il met des "1/2" à la place, ou des "?"...

Si je le converti en UTF8, les zones deviennent variables et donc je ne peux plus dire que par exemple la ville commencera bien en position 98.Car tous les caractères russes présents dans le fichier se sont mis sur 2 bytes alors que les autres sont restés sur 1 bytes.
Ca charge donc les données, en ignorant mes lettres russes et certaines variables sont tronquées.

Y a t-il un moyen de lui dire que je veux chargé de l'UTF8 ( soit dans la ligne de commande "sqlldr",soit dans mon "LOAD DATA" ) ?

**pifor** · 24/07/2006, 20h10

>Y a t-il un moyen de lui dire que je veux chargé de l'UTF8 ( soit dans la ligne de commande "sqlldr",soit dans mon "LOAD DATA" ) ?

Oui, il faut le définir avec la variable d'environnement NLS_LANG ou par le paramètre SQL*Loader CHARACTERSET.

Mais attention, si vous définissez le jeu de caractère défini par NLS_LANG égal à celui de la base, Oracle ne fera aucune vérification et aucune conversion: vous devez être absolument sûr de l'encodage des données: les caractères seront stockés dans la base tel quels. Et vous ne verrez les problèmes s'il y en a qu'à l'affichage des données ...

Je conseillerais plutôt si possible de choisir un jeu de caractères différent: dans ce cas là, en cas d'erreur de conversion, vous aurez l'erreur tout de suite au chargement.

Voir http://download-uk.oracle.com/docs/c...05.htm#1005288

**lolotte35** · 25/07/2006, 10h03

Merci, ça m'a beaucoup aidé!
Une doc très interressante avec des exemples c'est ce qu'il me fallait!

Je joins les paramètres de ma base.

J'ai ajouté dans mon fichier source :
LOAD DATA
CHARACTERSET UTF16
APPEND
INTO TABLE TMP_TIE_GAR2

J'ai testé avec CHARACTERSET UTF8 aussi.

Alors maintenant ça ressemble plus à du russe, mais le problème est que je charge les variables en fonction des positions dans le fichier de données, mais en UTF8 certaine données sont sur 1,2,ou 3 bytes et ça lors du chargement ça plante.

Pourtant lorsque je dis :
ADRESSE POSITION(1:40) CHAR,

Il prend l'adresse du caractère 1 à 40, mais si certains caractères sont sur 2 bytes la longueur du champ augmente, donc les variables suivantes sont décalées.

Dans mon fichier de données, il n'y a pas de démarcations entre les variables, alors y a til un moyen?

**lolotte35** · 25/07/2006, 16h45

J'ai réussi à charger mes données en UTF16, en ayant un fichier en UTF16 et en mettant dans mon fichier source :
LOAD DATA
CHARACTERSET UTF16

et en doublant toutes les variables, puisque que chaque caractère est sur 2 bytes.

donc par ex
ADRESSE POSITION(1:40) CHAR,
est passé à
ADRESSE POSITION(1:80) CHAR,

Maitenant, je voudrais vérifier que mes données sont correctes.
Lorsque je regarde par TOAD, je ne vois pas des caractères cyriliques,à la place je vois 2 caractères bizarres pour 1 caractères cyrilique.

Business Objetcs me donne le même résultat.

Lors de la création de la BDD, j'ai paramètré:
NLS_LANG=RUSSIAN et le NLS_TERRITORY=RUSSIA

maintenant, si je regarde das les tables NLS_DATABASE, c'est AMERICAN,
pour NLS_INSTANCE c'est RUSSIAN
pour NLS_SESSION c'est french

Est ce correct ?

Si je fais :
ALTER SESSION SET NLS_TERRITORY = Russia;
ALTER SESSION SET NLS_LANGUAGE = Russian;

Je ne vois pas de modification lors de l'affichage des noms de ville, adresse...

Est ce que je peux modifié un autre paramètre?
Connaissez vous un moyen pour lire mes données cyriliques?

Merci

**lolotte35** · 25/07/2006, 17h09

Avec sqldeveloper de Oracle j'ai réussi à visualiser mes données en Russe!

Maintenant reste à savoir comment les visualiser sous Business Objects....

Merci encore

**pifor** · 25/07/2006, 19h18

Pour avoir l'affichage correct, il faut positionner la variable d'environnement NLS_LANG avec le bon jeu de caractère: celui que Oracle sait interprèter et traduire correctement en utilisant les système d'exploitation client.

Code :

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

1
2
NLS_LANG=<language>_<territoire>.<jeu de caractères pour affichage côté client>

Pour l'affichage des caractères c'est le jeu de caractères qui est essentiel.
Le language et le territoire définissent la langue utilisée pour les messages SQLPLUS, les messages d'erreur, les formats d'affichage par défaut de la date, du temps, des nombres, de la monnaie ...

Sous Windows, il y toujours une valeur par défaut dans le registre. On peut la redéfinir dans un script avec:

Code :

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

set NLS_LANG=<nouvelle valeur>

**lolotte35** · 27/07/2006, 11h23

Bonjour,

Donc il faudrait faire sous windows :
set NLS_LANG=RUSSIAN_RUSSIA.AL32UTF8

Mais peut spécifié que l'on ne veut changer le NLS_LANG que de mon instance RUSSIE2 ?
Car j'ai plusieurs instances oracle sur mon serveur, qui est un serveur de production.

Autrement, cette BDD test "russie2" est sous linux.
Plus tard, je ne sais pas si nous mettrons la production sur un windows ou un linux...
Quelle est la commande pour changer le NLS_LANG sous un linux?

Merci

[SQL] charger données russes dans une BDD existante

SQL Oracle

Discussions similaires

Partager

Partager