Discussion :

[bruce-willis]

Bonjour,

J'ai l'erreur
ORA-06502 PL/SQL: numeric or value error character string buffer too small
sur un paramètre de type VARCHAR2 que je comprends pas du tout.

La seule utilisation de ce paramètre dans la procédure c'est une condition if

if (v_status <> '0')

Pour plus de précision, la valeur saisie dans ce paramètre est entrée au sein d'un code d'application utilisant ADO/ODBC (une VARIANT booléenne TRUE(-1)/FALSE(0))

[Snipah]

Comment est déclarée ta variable?

[bruce-willis]

v_status varchar2 est un argument de la procédure, je ne comprends ce qui peut-être d'insuffisant avec cela

[bruce-willis]

Le plus bizarre c'est:
ORA-06512: at line 1
C'est sur que ce paramètre qui est en cause mais il n'est pas en line 1!!!

Qui peut m'éclaircir?

REM: le plus bizarre c'est que j'ai réussi à passer 1 fois cette procédure et qu'une autre procédure un peu identique marche sans problème donc je me demande pourquoi il y a "buffer too small"??

[Arnaud F.]

Tu peux poster du code un peu plus complet nous permettant de voir le contexte?

[bruce-willis]

La procédure est très simple:

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
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
CREATE  OR REPLACE procedure dbo.deleteEast
  (
v_ID varchar2,
  v_Result  OUT int ,
  v_status varchar2 default '0',
  v_tool varchar2 := NULL)
 
 
AS  
 
   vson varchar2(38):=v_ID;
	vs varchar2(38);
	vfather varchar2(38);
	v_val DATE;
 
 
BEGIN 
 
 
		v_Result := -1;
 
 
		while (1=1) loop
 
		/* 1 step-forward*/
  			vs:=NULL;
 
			select ID into vs from westtable where IDParentGroup=vson ;
 
 
 
			if (vs is null) then
 
				/* step-forward fails 
				-- 2 staff on deletion*/
 
 				select IDParentGroup into vfather from westtable where ID=vson; 
 
				delete from northtable where IDGroup = vson;
				update quarktable SET IDGroup = NULL WHERE IDGroup = vson;
				delete from northtable where ID = vson ; 
 
 
 
 
				if(vson=v_ID ) then
					v_Result := 0;
					exit;
				end if;	
 
 
				vs:=NULL;
 
     			select ID into vs from  westtable where IDParentGroup=vfather and vson<>ID; 
 
 
				 if(vs is  NULL)then
					 vson:=vfather; /* return to parent so on next step of the loop to be deleted		*/
				 end if	;
 
				vson:=vs;
 
 
			end if ;
 
			vson:=vs;
 
 
 
 end loop;
 
if v_Result <> 0 then 
	ROLLBACK ;
	return;
else 
	commit;
	IF (v_status <> '0')then
		 ChangeTool(v_tool,v_val);
		Return;      
	end if;
	return	;
end if;

Pour le code C++ utilisant ADO, voici la variable en paramètre de la procédure

Code :

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

_variant_t varTemp_bStat = a_bStatus;

Puis on affecte juste ce _variant_t au Value d'un FieldPtr et c'est tout!!!
Et pourtant ça marche pas!

[bruce-willis]

Actuellement, j'ai réussi à reproduire plus précisement quand l'exception se déclenche.
J'ai essayé cette version simplifiée de la procédure:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
create or replace procedure TestVTBOOL
(
  v_ID varchar2,
  v_Res  OUT int ,
  v_status varchar2 default '0',
  v_text varchar2 := NULL
)
as
begin
  v_Res := -1;
  dbms_output.put_line(v_status);
end;

Quand on entre sur v_status la valeur '0', ORA-06502 se déclenche.
bIsStatus = false;
varTemp_bStat = bIsStatus;
Mais quand c'est '-1', 'abcd' la procédure passe très bien

et qu'une autre procédure un peu identique marche sans problème donc je me demande pourquoi il y a "buffer too small"??

En effet, l'exception n'apparaît que sur cette procédure de 4 param dont le 2è est un OUT. L'autre procédure est de 5 paramètres et ça passe

Le plus bizarre aussi c'est que j'obtiens comme v_Res (OUT param) dans mon application la valeur de v_status. Il est évident qu'il y a problème de mémoire là: Oracle ou ADO ou ODBC je ne sais plus

Je pense que c'est un bug ADO/ODBC!!!

[bruce-willis]

Le plus bizarre aussi c'est que j'obtiens comme v_Res (OUT param) dans mon application la valeur de v_status. Il est évident qu'il y a problème de mémoire là: Oracle ou ADO ou ODBC je ne sais plus

De plus, j'ajoute aussi cette autre remarque au cas où certains d'entre eux identifieraient le problème avec
1) Le problème se produit en fait lorsque v_status est vide ou de 1 caractère, il faut donc au moins 2 caractères
2) Même si c'est 2 kar et plus, on a encore l'erreur si v_Res (le retour OUT) est avec plusieurs chiffres comme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE OR REPLACE procedure TestVTBOOL
(
  v_ID varchar2,
  v_Res  OUT int ,
  v_status varchar2 DEFAULT '0',
  v_text varchar2 := NULL
)
AS
begin
  v_Res := 555555;
  dbms_output.put_line(v_status);
end;

Que déduis-je de cela ???

L'exécution sous SQL*PLUS du code suivant est 100% OK

Code :

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

1
2
3
4
5
6
7
set serveroutput on
declare
n int;
begin
testvtbool('aaa',n,'FALSE','sfqsdfqsfqs');
dbms_output.put_line(n);
end;

C'est sous ADO/ODBC que le problème apparaît

[randriano]

Mes petites expériences avec OleDb (ADO) et Oracle m'ont prouvé des bizarreries de ce genre! (le OUT prend toujours la valeur de v_status alors que v_Res est toujours affecté, pourquoi un changement de v_Res de type int peut planter la procédure)

[mnitu]

...
Que déduis-je de cela ???

L'exécution sous SQL*PLUS du code suivant est 100% OK
...
C'est sous ADO/ODBC que le problème apparaît

Qu’il y a un problème de binding entre les variables du langage que tu utilise (VB, C#, etc) et les paramètres passées à la procédure ! Donc en plus du code de la procédure tu devrait poster la déclaration des variables et l’appel à la procédure pour pouvoir juger correctement de la situation. Cella n’exclut pas des bugs dans Ado/Odbc, etc.

[bruce-willis]

Qu’il y a un problème de binding entre les variables du langage que tu utilise (VB, C#, etc) et les paramètres passées à la procédure ! Donc en plus du code de la procédure tu devrait poster la déclaration des variables et l’appel à la procédure pour pouvoir juger correctement de la situation. Cella n’exclut pas des bugs dans Ado/Odbc, etc.

J'ai vérifié, c'est pas un problème de binding!!!
Le problème c'est en fait le placement du paramètre OUT: souvent je met les out en derniers mais cette fois, c'est en 2è place. Donc, bizarrement, il reçoit comme valeur après exécution de la procédure la valeur du 3è paramètre, le 3è reçoit celle de 4è et ainsi de suite (le dernier paramètre est NULL)

[mnitu]

J'ai vérifié, c'est pas un problème de binding!!!
Le problème c'est en fait le placement du paramètre OUT: souvent je met les out en derniers mais cette fois, c'est en 2è place. Donc, bizarrement, il reçoit comme valeur après exécution de la procédure la valeur du 3è paramètre, le 3è reçoit celle de 4è et ainsi de suite (le dernier paramètre est NULL)

Et comment tu t'expliques qu'en sqlplus il n'y a pas de problème ? Le problème du binding peut exister au niveau des couches ADO/ODBC. Mais comment juger sans les déclarations des variables et le code d'appel de la procédure ?
Sinon en PL/SQL il n'y pas de restrictions sur le positionnement des paramètres OUT.

[bruce-willis]

Et comment tu t'expliques qu'en sqlplus il n'y a pas de problème?
.......................
Sinon en PL/SQL il n'y pas de restrictions sur le positionnement des paramètres OUT.

En fait, tout est de ma faute, normal s'il y a "string buffer too small" car le paramètre VARCHAR2 est copié par erreur dans le paramètre OUT qui n'est que de type INT!!!! Fausse manipulation d'exécution de procédure sous ADO (CommandPtr)