ORA-06502 parametre de sortie pose probleme

Version imprimable

19/10/2005, 15h44
Mons

ORA-06502 parametre de sortie pose probleme

bonjour !

J'appele une procedure dans un package qui a un parametre de sorti en varchar2.
Apparement quand la variable depasse une certaine taille, une erreur -06502 est levé.
Pourtant le champs qui remplie ma variable est un varchar2(40) ce qui ne me semble pas enorme.

Ma base est une 8.1.7 et j'appele l'appli via le web.

J'ai vu une histoire de buffer string trop petit sur internet mais je ne sais pas ce que c'est.
19/10/2005, 15h47
Jaouad

Bonjour ,
Peux tu donner ton code
merci

Jaouad

Avec grand plaisir :)

voici le code de la procedure appelante(résumé):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Procedure appelante(
    wmsgres out varchar2,
    type_origine  in varchar2,
    code_origine  in varchar2
)is
    wcndct table.champ%type;
 
 
begin
  wcndct := '';
 
    package.procedure(
        wMsgRes ,
        type_origine ,
        code_origine ,
        wcndct,
        libelle_groupe_oper ,
        libelle_bat_esc ,
        libelle_rue ,
        code_postal ,
        ville );

et celle de la procedure appelée (résumée aussi):

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
 
  Procedure appelée(
          wMsgRes OUT VARCHAR2,
          type_origine in varchar2,
          code_origine in varchar2,
          v_cndct in out long,
          libelle_groupe_oper   in out varchar2,
          libelle_bat_esc       in out varchar2,
          libelle_rue           in out varchar2,
          code_postal           in out varchar2,
          ville                 in out varchar2
  ) is
 
 
   BEGIN
 
      begin
      select C.cndct
      into wcndct
      from table C
      where C.cnct		= code_origine
      and   C.ctct		= type_origine ;
      exception when others then
      	wmsgres := 'ProblÞme de rÚcupÚration intitulÚ !' ;
           goto BeforeExit;
 
      end ;

le wcndct est en long mais j'ai aussi essayé en varchar2, en table.champs%type mais rien n'y a fait ...

19/10/2005, 15h56
Mons

ah oui ...

dans ce cas l'erreur est catchée mais si je demande le SQLCODE de l'erreur elle me ramene ORA-06502
19/10/2005, 16h09
Jaouad

il me faudrait l'erreur lors de l'éxècution

Merci
19/10/2005, 16h19
plaineR

C'est très résumé, il manque la déclaration de la moitié des variables out :?

Et si tu déclares ta variables wcndct en long, cela donne quoi ?

avec

Code:

1
2
3
4
5
6
 
EXCEPTION
    WHEN OTHERS THEN
        lnbErrNum := SQLCODE;
        lErrMsg := SQLCODE||SUBSTR(SQLERRM, 1, 150);
         wMsgRes := lErrMsg;

j'ai :

Code:

1
2
3
4
5
 
Une erreur :
-6502: ORA-06502: PL/SQL : erreur numérique ou erreur sur une valeur: erreur de conversion des caractères en chiffres
est survenue dans le traitement de l'erreur
-6502ORA-06502: PL/SQL : erreur numérique ou erreur sur une valeur: tampon de chaîne de caractères trop petit

19/10/2005, 16h25
Mons

même probleme avec variable en long
19/10/2005, 16h30
plaineR

Quelle est la longueur du champ que tu ramènes dans ton select ?

Pour info, long en pl/sql est limité à 32760 caractères alors qu'en base il peut contenir des chaînes de 2 Go.
19/10/2005, 16h30
Mons

varchar2(40)

ou as-tu ajouter ton exception :

Code:

1
2
3
4
5
EXCEPTION 
    WHEN OTHERS THEN 
        lnbErrNum := SQLCODE; 
        lErrMsg := SQLCODE||SUBSTR(SQLERRM, 1, 150); 
         wMsgRes := lErrMsg;

:?:

Juste apres :

Code:

1
2
3
4
5
6
7
8
9
10
package.procedure( 
        wMsgRes , 
        type_origine , 
        code_origine , 
        wcndct, 
        libelle_groupe_oper , 
        libelle_bat_esc , 
        libelle_rue , 
        code_postal , 
        ville );

:?:

19/10/2005, 16h50
Mons

non je l'ai mise dans la procedure appelée
19/10/2005, 16h55
Mons

:idea:

je pense que la bonne voie est celle du tampon de chaîne trop petit.
si quelqu'un sait ce que c'est ?
19/10/2005, 17h07
plaineR
Ca veut dire que tu essaies de mettre une chaine de caractères trop longue dans ta variable déclarée
exemple :
Code:

1 2 3 4 5 6 declare v_ch varchar2(1), begin v_ch := 'oui'; end; /
19/10/2005, 17h09
plaineR

Je ne suis pas sûr que cela vienne uniquement de wcndct, regarde également la longueur maxi de tes autres variables out, et plus particulièrement de wMsgRes :wink:
19/10/2005, 17h11
Mons
euh oui je veux bien mais ma variable est declaré de cette sorte
Code:

1 2 variable table.champ%type;
puis je fais un
Code:

1 2 select champ from table into variable;
j'ai essayé en déclarant ma variable en varchar2(40) et en long

rien n'y a fait
19/10/2005, 17h13
Mons

non ca vient de wcndct

j'excute mon code sans lui ca marche
avec lui ca ne marche pas

ca ne vient pas de wmsgres pour des tonnes de raisons je n'ai aucun doute là dessus ;)
19/10/2005, 17h40
plaineR

Que te ramène ta requête sous SQL*Plus

Citation:

select C.cndct
from table C
where C.cnct = code_origine
and C.ctct = type_origine ;

- pour un code et un type pour lesquels l'erreur se déclenche ?
- pour un code et un type pour lesquels l'erreur ne se déclenche pas ?
19/10/2005, 17h41
plaineR

Ce qui me semble bizarre, c'est :

Citation:

Une erreur : -6502: ORA-06502: PL/SQL : erreur numérique ou erreur sur une valeur: erreur de conversion des caractères en chiffres
est survenue dans le traitement de l'erreur ...
19/10/2005, 17h46
Mons

pour le traitement de l'erreur je crois que je sais ce que c'est ...
à force de tout tester je code comme un goré et du coup mon package de gestion d'erreur n'apprécie pas trop...

mais je n'avais pas remarqué. Mais cela implique que l'erreur qui me gene est la deuxieme.

la requete sous sql plus marche à tout les coups.

elle me plante dans le package apparement quand le champ dépasse une certaine taille.
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....