sqlldr et format date

Version imprimable

28/12/2006, 12h19
crazykangourou

sqlldr et format date
Bonjour à tous,

J'utilise sql loader pour exporter/importer des données sur oracle 9i installé sur windows xp pro.

Je rencontre le problème suivant :

Lorsque j'importe des données : les formats date et numérique cause des erreurs :
dans les fichiers dat les format date sont DD/MM/YYYY et les numeric =', '

Une demi solution : avant de faire l'import depuis un poste sous linux (ubuntu) je fais :
Code:

1 2 export NLS_DATE_FORMAT='DD/MM/YYYY HH24:MI:SS' export NLS_NUMERIC_CHARACTERS=', '
Et là l'importation se déroule sans erreur.

Alors que sur un autre poste (red hat), si je suis la même procédure (export NLS...), j'ai quand même des erreur dues au format date et numeric. Comme si mes paramètres NLS n'étaient pas pris en compte.
Dans le log, l'erreur me dit le format mois n'est pas valide !!!
Je précise que si je tape la commande env : je visualise bien mes paramètres NLS que je viens de définir.

Quelqu'un a une idée?
Je souhaiterais ne pas retoucher les fichiers.ctl pour redéfinir le format des colonnes, j'en ai un bon paquet.

Merci d'avance.
28/12/2006, 14h06
pifor

S'agit-il des mêmes instances ? Avec le même compte utilisateur ?
Un trigger sur logon pourrait expliquer cette différence de comportement.

Vérifiez que vous avez le même résultat dans les 2 cas pour:

Code:

select * from nls_session_parameters where parameter like '%DATE%';

après avoir positionné au niveau shell les variables NLS_xxx.

1°) Assure toi du format de tes exports, toujours le même !

2°) donne la même définition de format dans tes imports dans le controleur .ctl

Code:

DAT_CREA POSITION(397:404) date "YYYYMMDD" NULLIF DAT_CREA='00000000'

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
SQL> select to_number('1.2','99999999999999D99','NLS_NUMERIC_CHARACTERS=''. ''')from dual;
 
TO_NUMBER('1.2','99999999999999D99','NLS_NUMERIC_CHARACTERS=''.''')
-------------------------------------------------------------------
                                                                1,2
 
SQL> select to_number('1,2','99999999999999D99','NLS_NUMERIC_CHARACTERS='', ''')from dual;
 
TO_NUMBER('1,2','99999999999999D99','NLS_NUMERIC_CHARACTERS='',''')
-------------------------------------------------------------------
                                                                1,2
 
SQL> 
LOAD DATA
...
into table 
....
(
geom position(9999) "to_number(:geom,'99999999999999D99999999999','NLS_NUMERIC_CHARACTERS='',.''')"
...
)

L'exemple sur les number sont tirés d'ici

Comme ca quel que soit ton séparateur ca fonctionne

28/12/2006, 17h05
crazykangourou

Pifor,
Effectivement sur la redhat, je n'ai pas les même parametres de session sur les date quand j'execute la requete suivante dans sqlplus.

Code:

SELECT * FROM nls_session_parameters WHERE parameter LIKE '%DATE%';

qui me donne le résultat suivant : NLS_DATE_FORMAT='DD/MON/RR'

Pourtant avant de me connecter sous sqlplus, je fait bien sur mon compte utilisateur "root"

Code:

export NLS_DATE_FORMAT='DD/MM/YYYY'

Où est ce que je me goure????

Merci sygale pour ta réponse, mais comme je le disais dans le post initial, je ne veux pas toucher à mes ctl
PS : le lien n'a pas l'air de fonctionner
28/12/2006, 17h25
pifor

Essayez:

Citation:

export NLS_DATE_FORMAT="DD/MM/YYYY"

Il ne devrait pas y avoir de simple ou double quote dans les valeurs affichées par

Code:

SELECT * FROM nls_session_parameters WHERE parameter LIKE '%DATE%';
28/12/2006, 18h43
remi4444

sous sqlplus, gaffe au fichier sournois $ORACLE_HOME/sqlplus/admin/glogin.sql :aie:
29/12/2006, 09h23
crazykangourou

Bonjour,

Je reviens à la charge,
J'ai essayé

Code:

export NLS_DATE_FORMAT="DD/MM/YYYY"

Mais de toute manière avec des doubles ou simples quotes, lorsque je fais : sous la redhat env : j'ai bien ma variable initialisée :

Code:

NLS_DATE_FORMAT=DD/MM/YYYY

Les simples ou doubles quotes disparaissent.

Non, je pense que le problème viens du fait que mes variables d'environnement ne sont pas prises en compte car elles ne sont pas reconnues par sqlldr.
Je pense qu'il faut que je définisse autres choses aussi, mais quoi?

En tout cas quand je me connecte sous sqlplus,

Code:

NLS_DATE_FORMAT=DD-MON-RR

:oops:
29/12/2006, 09h35
pifor

Le fichier glogin.sql ne concerne qu'une session SQL*Plus: il n'est pas pris en compte pour une session SQL*Loader.

Avez-vous vérifié s'il y a un logon trigger ?
Quelle est la version de sqlldr sur la machine concernée ?
La base est hébergée sur Windows XP et sqlldr est sur Linux ? C'est une configuration un peu bizarre.

Vous pouvez essayez de mettre en place le logon trigger avec la bonne valeur pour NLS_DATE_FORMAT: http://asktom.oracle.com/tkyte/Misc/NLSDateFormat.html
29/12/2006, 10h33
crazykangourou

pifor,

Je sais la config est un peu bizzard, mais ce n'est qu'une config de test le serveur sera sous linux à terme, c'est juste pour tester les transferts de données avec sql loader.
Heureusement qu'on fait les tests ;)

Pour répondre à tes questions, je n'ai pas de trigger logon, (de plus ca marche avec la 1er machine sous ubuntu) et je n'ai pas non plus de fichier init.ora que j'ai rechercher avec locate init.ora. Je pense que c'est normal, car sur la redhat, il n' y a que le client oracle qui est intallé (9.2i)

Ca m'embete de faire un trigger logon juste pour ca, en plus il faudra la faire chez le client aussi, c'est un peu embetant.....
29/12/2006, 10h58
nuke_y

Surtout que chez le client ça marchera ptet comme il faut...
29/12/2006, 10h59
pifor

Il faudrait essayer de faire un test avec la base sur un serveur Linux ou au moins avec Windows Server 200X. Oracle supporte Windows XP Pro mais pas Windows XP Home: http://www.oracle.com/technology/tec....html#versions
29/12/2006, 13h35
crazykangourou

D'accords, la config est bizzard,

Mais ne nous égarons pas :
Il faut bien garder en tête que depuis un poste avec ubuntu, j'arrive a définir correctement mes variable d'environnement (export NLS...) confirmés grace à sqlplus,
ET que sur un autre poste (red hat), je suis les mêmes étapes MAIS, je n'ai pas les mêmes variables définies dans sqlplus CF ????

Les 2 postes linux voulant se connecter sur 1 SEUL même poste win xp pro.

Je suis d'accords, peut être que chez le client ca marchera, mais si ca ne marche pas...:oops:
29/12/2006, 15h14
remi4444

c'est le meme shell que tu utilise des 2 cotés ?
tu as la meme variable NLS_TERRITORY ?
29/12/2006, 15h26
remi4444

et NLS_LANG ?
29/12/2006, 16h47
crazykangourou
Sur le poste où est installé ubuntu :
Code:

1 2 3 SHELL=/bin/bash NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252
Et sur la red hat je n'ai qu'un pauvre

Code:

LANG=fr_FR.UTF-8
29/12/2006, 16h51
crazykangourou

Merci Pifor
Merci pifor,

grace à toi, ca fonctionne, j'ai fait un
Code:

1 2 export NLS_LANG=FRENCH_FRANCE.WE8MSWIN1252 NLS_DATE_FORMAT=DD/MM/YYYY
Et ca ...
Marche !!!!!!!!!!

Par contre, je ne peux pas me contenter de dire, ca marche, j'aimerai comprendre pourquoi???
Est ce trop demander une petite explication?

Heureusement que vous êtes là pour conseiller des débutants comme moi je commence sous linux et ca fait quelques mois que je tripatouille oracle.

Merci encore
29/12/2006, 17h48
pifor

D'après le document suivant http://www.oracle.com/technology/tec...lang%20faq.htm,
et le problème que tu as eu, on peut déduire que la variable d'environnement NLS_DATE_FORMAT n'est prise en compte que si la variable d'environnement NLS_LANG est définie, sinon ce sont les valeurs par défaut qui s'appliquent.

PS: merci à, rémi4444 en fait ;)
29/12/2006, 20h48
remi4444

de rien, de rien... ;)

J'avoue que j'ai jamais vraiment tout saisi aux multiples subtilités du système à tiroir de la gestion des formats de dates et autres paramètres nationaux. A n'en pas douter, le concepteur de tout ce fatras devait etre un esprit profondément pervers... :aie:

La documentation perméttant à quelqu'un de tres bien reposé d'entrevoir une logique fragile s'appelle "globalization":

http://download-uk.oracle.com/docs/c...9/ch3.htm#5014

Conclusion, il faut se fixer comme discipline de ne jamais laisser oracle faire de conversion implicite de date ni dans un sens ni dans l'autre. Utiliser systématiquement le to_date et le to_char peut paraitre fastidieux mais ça permet de mieux dormir la nuit ;)
31/12/2006, 11h32
crazykangourou

erratum

Je m'excuse,
rendons à césar ce qui est à césar!

Merci remi444!!!

PS : merci aussi à tous ceux qui ont pris la peine de proposer des pistes et des solutions.

Bonne fin d'année à tous et à l'année prochaine