ORA-06502 parametre de sortie pose probleme

Version imprimable

Voir 40 message(s) de cette discussion en une page

19/10/2005, 17h51
plaineR

Citation:

Envoyé par Mons

elle me plante dans le package apparement quand le champ dépasse une certaine taille.

As-tu réussi à déterminer cette taille ?

Sinon, peux tu me donner la valeur de C.cndct quand ça ne plante pas et quand ça plante ? (si les données sont confidentielles remplace toutes les lettres par X et tous les nombres par 0)
19/10/2005, 18h01
Mons

j'ai fait deux tests simples :

avec

Citation:

'jjjjjjjjjj'

ca marche

avec

Citation:

'jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj'

ca ne marche pas

je vais faire des tests avec des chaines de differentes longueurs pour déterminer la taille si tu as une idée en tête mais je n'ai pas envie de le faire pour rien.
19/10/2005, 18h20
plaineR

Non je n'ai aucune idée en tête... :roll:

N'utilises-tu pas wcndct ailleurs dans ta procédure appelée ? N'essaies-tu pas de copier cette variable dans une autre ?

[EDIT]Tu m'as dit que lorsque tu virais le select tu n'avais plus l'erreur, et si tu ne laisses que le select as-tu l'erreur ? [/EDIT]
20/10/2005, 10h48
Mons

:?

pff on pas toujours un métier facile .... dure matinée ....

bref, bon c'est clair que c'est un probleme de tampon de chaîne trop petit.

Il y a bien quelqu'un qui a déjà rencontré ce problème non ?
09/11/2006, 14h55
snake64

J'ai exactement le même....

J'ai une procédure stockée

Procédure(Param1 IN NUMBER, Param2 OUT VARCHAR2)
Begin
...
Param2 = 'une chaine de caractere de 700 :)'
End;

ma procédure plante:
ORA-06502: PL/SQL: numeric or value error: character string buffer too small

En fait j'aimerais connaitre comment configurer la taille de mon paramètre car il doit avoir une valeur par défaut.
Selon mes tests ma procédure craque a partir de 255. Hors j'ai une chaine de + de 700 a mettre dedans...
En oracle 8 varchar2 est sensé pouvoir faire 4000 mais SI on la déclare en VARCHAR2(4000).
Une parametre de procedure n'est pas "configurable"???
29/04/2009, 17h03
maniolo

Désolé de faire remonter un vieux post de derrière les fagots mais j'ai à peu près le même problème depuis plusieurs jours et je n'arrive pas à trouver de solution...deux dbas sont venus m'aider mais sans succès....

Voilà, j'ai plusieurs procédures qui font des update ou des insert qui me pètent au nez sans raisons :(, le pire c'est que ca fonctionne chez le client.
Par exemple j'ai un batch qui fait une mise à jour de certaines données issues d'un fichier, il les traite ligne à ligne. Lorsque sur une ligne, une des données comporte trop de caratère, en l'occurence il s'agit d'une adresse, j'ai le message :
ORA-06502: PL/SQL : erreur numérique ou erreur sur une valeur
ORA-06512: à ligne 1.

Cette adresse doit normalement être au maximum sur 32 caractères (en base ce champ est un VARCHAR2(32 BYTE)), dans mon cas, mon adresse doit faire au maximum 12 caractères pour que l'insertion fonctionne (J'ai essayé par exemple de mettre 12 lettres A ca fonctionne mais 13 lettres A non).

J'ai récupéré la requete en mode debug avec les valeurs des variables et cela fonctionne sous sql developper, j'ai également modifié à la volée la valeur de mon adresse lors du debug et cela fonctionne également.

Dans la procédure qui fait l'insertion, la variable est typé comme le champ (%TYPE). Dans le catch de ma procédure, j'ai rajouté le SQLCODE et le SQLERRM mais ca ne rentre jamais dedans!!!
J'ai créé un trigger qui fait un before update et qui m'insert les données dans une autre table mais il n'est jamais lancé, comme si oracle rejetait ma requête dès qu'il la recoit.

Voilà, j'ai tourné le pb dans tous les sens je ne sais vraiment plus quoi faire :cry:
29/04/2009, 17h39
Waldar

Votre base est-elle en unicode ?

Si oui, votre problème vient de ceci :

Citation:

Cette adresse doit normalement être au maximum sur 32 caractères (en base ce champ est un VARCHAR2(32 BYTE))

Si vous êtes en unicode, votre champ doit être un VARCHAR2(32 CHAR).
30/04/2009, 10h44
maniolo

Euh je ne sais pas, comment vérifier si ma base est en unicode?

Sinon en vérifiant la doc d'installation, j'ai remarqué une chose différente nls_lang est en américain dans mon .profile et en francais dans la doc, cela change quelque chose?

J'ai donc remplacé NLS_LANG :

Citation:

#export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
export NLS_LANG=FRENCH_FRANCE.WE8ISO8859P15
export NLS_DATE_FORMAT="DDMMYYYY HH24:MI:SS"
export NLS_NUMERIC_CHARACTERS=". "
export NLS_DATE_LANGUAGE="FRENCH"
30/04/2009, 11h47
maniolo

EN faisant des recherches je suis tombé sur ca sur le site :

Evitez les erreurs de conversion grâce aux NLS
Date de publication : 29.07.2006 , Date de mise à jour : 15.02.2009
Par Fabien Celaia (fadace)

http://fadace.developpez.com/oracle/nls/

du coup, en exécutant la requete ci-dessous, la modification de mon .profile
ne semble pas avoir changé grand chose, même apres un arret de la base...
sinon, il semblerait que la base soit en UTF16?

Citation:

select * from NLS_DATABASE_PARAMETERS ;

PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .
NLS_CHARACTERSET WE8ISO8859P15
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DDMMYYYY HH24:MI:SS
NLS_DATE_LANGUAGE FRENCH
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 9.2.0.6.0

20 rows selected
30/04/2009, 11h52
Waldar

Oui effectivement.
Essayez en modifiant le paramètre NLS_LENGTH_SEMANTICS à CHAR.

Ok mais apparemment j'ai peut etre un trigger qui me positionne la variable à chaque session...
En faisant la requete ci dessous je vois que j'ai bien un trigger logon mais ce qu'il fait....

Code:

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

le trigger

Code:

1
2
3
4
5
6
 
CREATE OR REPLACE TRIGGER SYS.sys_logon
after logon
on database
CALL logon_proc;
/

la proc 8O

Code:

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
CREATE OR REPLACE procedure SYS.logon_proc wrapped
0
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
3
7
9200000
1
4
0
6
2 :e:
1LOGON_PROC:
1SYS:
1LT_CTX_PKG:
1SETSESSIONATTRIBUTES:
1DBMS_SESSION:
1UNIQUE_SESSION_ID:
0
 
0
0
18
2
0 9a b4 55 6a :2 a0 6b a0
6b :2 a0 6b a5 57 b7 a4 b1
11 68 4f 1d 17 b5
18
2
0 3 17 18 1c 20 24 28
2b 2f 32 36 3a 3d 3e 43
45 49 4b 57 5b 5d 5e 67
18
2
0 b 0 :2 1 3 :2 7 :2 12 27
:2 34 :2 3 :9 1
18
4
0 1 0 :2 1
:a 3 :2 2 :7 1
69
4
:3 0 1 :a 0 13
1 :8 0 2 :2 0
13 1 3 :2 0
2 :3 0 3 :3 0
5 6 0 4
:3 0 7 8 0
5 :3 0 6 :3 0
a b 0 3
9 d :2 0 f
5 12 :3 0 12
0 12 11 f
10 :6 0 13 :2 0
1 3 12 16
:3 0 15 13 17
:8 0
7
4
:3 0 1 c 1
e
1
4
0
16
0
1
14
1
1
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0
1 0 1
0
/

J'ai modifié le paramètre de session nls_lenght_semantics mais j'ai toujours le pb

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ALTER SESSION SET NLS_LENGTH_SEMANTICS = 'CHAR'
 
NLS_LANGUAGE	FRENCH
NLS_TERRITORY	FRANCE
NLS_CURRENCY	€
NLS_ISO_CURRENCY	FRANCE
NLS_NUMERIC_CHARACTERS	,.
NLS_CALENDAR	GREGORIAN
NLS_DATE_FORMAT	DD/MM/RR
NLS_DATE_LANGUAGE	FRENCH
NLS_SORT	FRENCH
NLS_TIME_FORMAT	HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT	DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT	HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT	DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY	€
NLS_COMP	BINARY
NLS_LENGTH_SEMANTICS	CHAR
NLS_NCHAR_CONV_EXCP	FALSE

04/05/2009, 14h59
maniolo
J'ai une nouvelle piste assez étrange, en arretant puis redemarrant ma base oracle, la valeur qui me générait une erreur ne pose plus de pb,la mise à jour est bien faite :roll:
j'ai fait le test plusieurs fois et cela fonctionne à chaque fois...

dans mon fichier init.ora, je ne sais pas si cela peut jouer mais j'ai plusieurs paramètres de cache, je ne sais pas s'ils sont bien paramétrés et si cela peut jouer :
Code:

1 2 3 4 5 6 ########################################### # Cache and I/O ########################################### db_block_size=8192 db_cache_size=209715200 db_file_multiblock_read_count=16
06/05/2009, 10h15
maniolo

Mon problème ne semblant amasser les foules, je l'ai exposé sur le forum de metalink, voici ce que l'on m'a répondu :

Citation:

Hi,
usually this error is raised because the configuration and translation between bytes and Varchar2.
The NLS_LENGTH_SEMANTICS allows you to specify the length of a column datatype in terms of CHARacters rather than in terms of BYTEs.
Typically this is when using an AL32UTF8 or other varying width NLS_CHARACTERSET database where one character is not always one byte.
While using CHAR semantics has as such no added value in a 7/8 bit characterset it's fully supported so any application code / table setup using CHAR
can also be used in a 7/8bit characterset like US7ASCII/WE8MSWIN1252.

Je lui ai alors répondu que j'avais déjà essayé de modifier le paramètre NLS_LENGTH_SEMANTICS dans les paramètres de session mais que cela n'avait rien changé, il m'a alors demandé un exemple et voici ce que je lui ai répondu (et on ne se moque pas de mon écriture :lol:), j'attends dorénavant une réponse :

Citation:

Hi, it's clearly a problem of conversion, but i don't know how resolve it and give you an example is not easy.

for example there is this address "RUE LOUISE DE SAVOIE" corresponding to the column LIB_RUE who generate this error. Here we have twenty characters with blank. If I modify LIB_RUE in VARCHAR2 (60 Char) the update works otherwise with a VARCHAR2 (32 Char) it doesn't work. except if i shutdown and restart the database.

To summarize, I made few change :

I replace all byte by char for data type in the table. so now my column LIB_RUE is now VARCHAR2 (32 Char)

In the init.ora i add this line : nls_length_semantics=CHAR

NLS parameters from instance, session and db :

SELECT * FROM NLS_INSTANCE_PARAMETERS;

NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_SORT
NLS_DATE_LANGUAGE FRENCH
NLS_DATE_FORMAT DDMMYYYY HH24:MI:SS
NLS_CURRENCY
NLS_NUMERIC_CHARACTERS .
NLS_ISO_CURRENCY
NLS_CALENDAR
NLS_TIME_FORMAT
NLS_TIMESTAMP_FORMAT
NLS_TIME_TZ_FORMAT
NLS_TIMESTAMP_TZ_FORMAT
NLS_DUAL_CURRENCY
NLS_COMP
NLS_LENGTH_SEMANTICS CHAR
NLS_NCHAR_CONV_EXCP FALSE

-------------------------------------------------------------------------------------------------------------------

SELECT * FROM NLS_SESSION_PARAMETERS;

NLS_LANGUAGE FRENCH
NLS_TERRITORY FRANCE
NLS_CURRENCY ?
NLS_ISO_CURRENCY FRANCE
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD/MM/RR
NLS_DATE_LANGUAGE FRENCH
NLS_SORT FRENCH
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY ?
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS CHAR
NLS_NCHAR_CONV_EXCP FALSE

-------------------------------------------------------------------------------------------------------------------

SELECT * FROM NLS_DATABASE_PARAMETERS;

NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .
NLS_CHARACTERSET WE8ISO8859P15
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DDMMYYYY HH24:MI:SS
NLS_DATE_LANGUAGE FRENCH
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 9.2.0.6.0

I was wondering if the parameter NLS_NCHAR_CHARACTERSET in AL16UTF16 wasn't the problem?

La piste que je pensais bonne, à savoir changé le AL16UTF16 en AL32UTF8, ne l'ai pas car chez le client la config est comme ceci :

Citation:

PARAMETER VALUE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8ISO8859P15
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 9.2.0.5.0

Et donc le truc qui vraiment me dépasse c'est pourquoi après avoir arrêter et redémarrer l'instance de ma base, la ligne qui ne passait et bien... passe

:D ayé!, le fait de passé en 9.2.0.5 au lieu de 9.2.0.6 a corrigé le problème, il semblerait qu'il y ai un bug, pourtant la personne de metalink qui m'a aidé connaissait ce problème sur une autre version (bug 4572934).

Voilà, je vous mets la suite de la discussion si cela interesse quelqu'un :

metalink :
Citation:
Hi, it might be the bug 4572934 depending on the version you are using.
Try the following code:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 DECLARE v_ret_date CHAR(8 BYTE); -- this fails in 10g -- v_ret_date CHAR(8); this works PROCEDURE proc2(o_ret_date OUT CHAR ) IS BEGIN o_ret_date := to_char(SYSDATE, 'YYYYMMDD'); END ; PROCEDURE proc1 (o_ret_date OUT CHAR) IS BEGIN proc2 (o_ret_date); END; BEGIN proc1 (v_ret_date); END; /
moi

Citation:

Hi,

Actually, by changing the database, I have actually no more problems. What is strange is that I change the version 9.2.0.6 by the version 9.2.0.5.
Do you know if there is a patch for version 9.2.0.6 which resolves the problem?

mon pote meta :

Citation:

Hi,
not sure about any patches exist for 9.2.0.6 which fix your issue, But latest supported version for 9.2 DB is 9.2.0.8.
Oracle recommend to stay up to date on latest supported patch set level.
Regards,
GiovanniR - Moderator
Comme ce post est très vieux et que je n'en suis pas à l'origine si un modérateur ou Mons veulent le fermer....

Voir 40 message(s) de cette discussion en une page