Discussion :

[atanabe]

bonjour,
voulant executer une procedure stockée depuis ma machine unix, j'obtient l'erreur suivante que j'avoue , ne pas arriver à comprendr.

ERROR at line 1:
ORA-01858: a non-numeric character was found where a numeric was expected
ORA-06512: at "SYSADM.EXTACT_CDR", line 134
ORA-06512: at line 1

voici mon code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 ORACLE_HOME=/home1/oracle/app/oracle/product/8.1.6
 #ORACLE_HOME=/export/home/oracle/OraHome1
 
 export ORACLE_HOME
 PATH=/bin:/usr/bin:/usr/sbin:/opt/bin:/usr/ccs/bin:/opt/local/GNU/bin:/opt/local/bin:/opt/NSCPnav/bin:$ORACLE_HOME/bin
 export PATH
 cd /d3/instances/b5c/work/di/von
 sqlplus sysadmin/sysadmin@B5C << END
 exec extact_cdr;
 END

!!je tiens à preciser que ma procedure marche bien qd je l'execute avec toad.
merci pour votre aide

[Oraman]

Bonjour,
cette proc ne prend aucun paramètres ?
est ce que la compilation passe sans aucun pb ?
regarde la ligne 134 quest qu'il y a comme affectattion ?

[Oraman]

as tu un pb de ',' et '.' lorsque tu affecte un Number(x,y) ?

[atanabe]

ok!g deja initialisé toute les parametres donc plus de params.
à la ligne 134 il y a

Code :

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

1
2
3
4
 
...
fetch curs into li1,li2,li3;
...

des variables que j'ai declaré plus haut dans cette procedure comme suit

Code :

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

1
2
3
4
 
li1 varchar(25);
li2 varchar(25);
li3 varchar(25);

[Oraman]

verifie si les colonnes ramené par le fetch sont du même type que les variables ?

[remi4444]

Vérifie surtout que tu n'a pas de conversion implicites, (du style remplir un champ date ou numérique avec une chaine de caractère etc...)

ce genre de chose est classique parceque les paramètres NLS sont dépendant de la session qui appelle la procédure

[atanabe]

Merci remi4444,
en fait, le bug est sur la clause 'where' de la requête.
.

Code :

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

lc$where='to_char(ddate,'dd/mm/yyyy')='(sysdate-1);'

je voulait obtenir les informations de la date d'hier.
la variable qui contient la date est ldate :

Code :

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

1
2
ldtate   varchar2(25);
          vmesg  varchar2(25)

ceci est appelé dans:

Code :

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

fetch cur into ldate||CHR(9)||vmesg;

j'ai deja mis LC$where dans to_char, et ldate est type varchar, pourquoi, il y il encore un bug?

en plus, la requête ne ramène aucune ligne alors que qd je remplace (sysdate-1) par la date d'hier, ex:18/08/2006, la requête ramene des lignes.Savez vous aussi comment résoudre ce pb?
merci pour votre réponse.

[Pomalaix]

Bonjour

Ca ne serait pas truffé de fautes de frappe, ce que vous nous présentez ?
Entre ldate, ddate, et ldtate, on a du mal à y retrouver ses petits !!

Quoi qu'il en soit, si la valeur en dur fonctionne, mais pas l'appel à sysdate, c'est que vous avez un bête problème de format de date.

Code :

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

lc$where='to_char(ddate,'dd/mm/yyyy')='(sysdate-1);'

Ne pas oublier qu'une date est systématiquement stockée par Oracle avec les heures, minutes et secondes, et que lors d'une comparaison, tous ces éléments sont pris en compte.
SYSDATE renvoie aussi une date dont la précision va jusqu'aux secondes.

Si besoin, il faut donc arrondir vos dates via TRUNC ou ROUND avant de les comparer.

Petites remarques au passage :
- stocker une date dans un VARCHAR2 est probablement une mauvaise idée, puisque cela vous oblige à des transtypages
- il faut comparer des éléments de même type (DATE avec DATE, VARCHAR2 avec VARCHAR2)
- ne pas utiliser inutilement les fonctions de conversion TO_CHAR ou TO_DATE

[remi4444]

je suis entièrement d'accord avec pomalaix, il faut comparer des variables de même type, sinon on fait faire au langage des conversions implicites, ce qui rend le comportement du programme instable. Quand j'ai appris l'informatique, c'était la mode du C, et tous les profs nous expliquaient que les langages autorisant les conversions implicites étaient archaïques et dangeureux, en voici encore une parfaite illustration:

lorsque se fait la comparaison de (sysdate -1) avec to_char(machin, machin_format), le langage va d'abord faire la conversion de ton (sysdate - 1) en chaine de caractère avant de le comparer avec le to_char. Meme mieux, si ta variable ddate est de type caractère, elle va d'abord etre convertie en date car le to_char veut une date en 1ier argument.... Mais le format de conversion de la date dépend de la variable session NLS_DATE_FORMAT, qui dépend du paramétrage de ton client oracle. Donc ça se peut trés bien que ça fonctionne depuis chez toi et que ça ne fonctionne plus depuis ailleur...

Je te conseille donc vivement de faire les conversion toi meme afin de t'assurer que tu compare bien des donnés de même type.