[Oracle 10g] j'arrive pas à changer NLS_LENGTH_SEMANTICS

**fguigui** · 20/04/2007, 11h18

Bonjour à tous,

En se connectant à oracle par sqlplus en tant que dba, nous avons modifié NLS_LENGTH_SEMANTICS, en faisant :

Code :

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

1
2
3
alter system set NLS_LENGTH_SEMANTICS=CHAR scope=spfile
shutdown immediate
startup

En se connectant avec ce login dba, on retrouve bien NLS_LENGTH_SEMANTICS=CHAR.

En se connectant avec un autre login, on récupère l'ancienne valeur :
NLS_LENGTH_SEMANTICS=BYTE

Nous avons modifié le registry NLS_LANG du client avec différentes valeurs :
FRENCH_FRANCE.WE8MSWIN1252
AMERICAN_AMERICA.WE8ISO8859P1

Ca marche toujours pas.

Comment faire pour récupérer NLS_LENGTH_SEMANTICS=CHAR avec les autres login Oracle ?

Merci d'avance.

Cordialement.

**orafrance** · 20/04/2007, 11h51

n'y aurait-il pas un trigger ON_LOGGON ?

**pifor** · 20/04/2007, 12h01

Ou bien le code applicatif execute peut-être sans trigger:

ALTER SESSION SET NLS_LENGTH_SEMANTICS=BYTE

**fguigui** · 20/04/2007, 12h03

comment qu'on le voit sous sqlplus ?

**fguigui** · 20/04/2007, 12h06

Envoyé par pifor

Ou bien le code applicatif execute peut-être sans trigger:

ça marche pas avec sql*loader ! (ou alors je ne sais pas faire)

**fguigui** · 20/04/2007, 12h07

Envoyé par orafrance

n'y aurait-il pas un trigger ON_LOGGON ?

comment on le voit sous sqlplus ?

**bouyao** · 20/04/2007, 12h08

Est ce que tu arrête la base après les modifications ?

**fguigui** · 20/04/2007, 12h10

Envoyé par bouyao

Est ce que tu arrête la base après les modifications ?

on fait shutdown immediate puis startup

**pifor** · 20/04/2007, 12h18

Les triggers ON LOGON sont listés par:

Code :

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

1
2
3
4
 
select owner, trigger_name, triggering_event 
from dba_triggers
where triggering_event='LOGON';

**fguigui** · 20/04/2007, 12h40

Envoyé par pifor

Les triggers ON LOGON sont listés par:

Code :

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

1
2
3
4
 
select owner, trigger_name, triggering_event 
from dba_triggers
where triggering_event='LOGON';

SELECT owner, trigger_name, triggering_event
FROM dba_triggers
WHERE triggering_event='LOGON';

no rows selected

**fguigui** · 20/04/2007, 14h27

En fait, en faisant :

Code :

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

1
2
3
SELECT owner, trigger_name, triggering_event 
FROM dba_triggers
WHERE triggering_event like '%LOGON%';

Retourne un trigger qui effectivement modifie NLS_LENGTH_SEMANTICS, c'est un progiciel qui fait ça..., et on ne peut donc pas le modifier comme on veut.

Sinon c'est surtout au chargement de données par sql*loader que ça pose pb. Verriez-vous un moyen de modifier NLS_LENGTH_SEMANTICS pendant sqlloader ? (je n'en ai pas vu...)

**pifor** · 20/04/2007, 14h55

Je ne comprends pas l'intérêt de changer NLS_LENGTH_SEMANTICS pour une session SQL*Loader: SQL*Loader ne fait que du DML et non du DDL et ce paramètre ne me semble utilisé que par du DDL comme CREATE TABLE et ALTER TABLE et non par du DML comme INSERT ou UPDATE.

**fguigui** · 20/04/2007, 16h36

Envoyé par pifor

Je ne comprends pas l'intérêt de changer NLS_LENGTH_SEMANTICS pour une session SQL*Loader: SQL*Loader ne fait que du DML et non du DDL et ce paramètre ne me semble utilisé que par du DDL comme CREATE TABLE et ALTER TABLE et non par du DML comme INSERT ou UPDATE.

En fait nos pbs actuels viennent du fait que nous migrons notre application vers une bd oracle (même version que la précédente) dont les données textuelles sont à présent codées en utf8 (apparemment sur 16 ou 32 bits).

Dans le fichier ctl de sql*loader nous avons ce type de commande (pour un champ à charger) :

champ1 "substr(:champ1, 1, 20)",

ores ce qui fonctionnait avec la précédente codification, ne fonctionne plus en utf8, le substr ne limite plus à 20 car. les données en entrée (laisse passer 21, 22, 23, ou 24 car. ce qui fait planter sql*loader...) du fait que

NLS_LENGTH_SEMANTICS=BYTE

au lieu de

NLS_LENGTH_SEMANTICS=CHAR

Voila tout le pb !

J'espère que j'ai été clair !

Donc d'autres pistes :
- comment régler sqlloader pour qu'il ne plante plus dans ce cas ? (tronque de lui même à 20 car. et intègre les données).

- D'autres idées ?

Merci de votre aide.

**pifor** · 20/04/2007, 16h59

Si les données dans le fichier à charger sont encodées en UTF8, il faut utiliser la variable d'environnement NLS_LANG ou le paramètre CHARACTER_SET de SLQ*Loader, sinon si vous n'avez que de l'ASCII à charger il ne faut rien faire côté client et laisser Oracle faire la conversion dans la base.