[SQL/Oracle] - Programmation
Marsh Posté le 23-05-2001 à 17:01:25
C'est la première fois que je vois returning dans une requête ...
mais c'est stupide, vaux mieux mettre set numb = 0 where numb = 1
ou alors y'a une erreur dans la requête
Marsh Posté le 23-05-2001 à 17:09:29
ddr555 a écrit a écrit : C'est la première fois que je vois returning dans une requête ... mais c'est stupide, vaux mieux mettre set numb = 0 where numb = 1 ou alors y'a une erreur dans la requête |
Je suis tout a fait d'accord, en fait je me fous de cette partie je ne m'interresse qu'a la partie returning...into...
cette requete est un test et a l'origine c'etait numb = :entry
et pour simplifier.... enfin voila...
Mais merci quand meme
Marsh Posté le 23-05-2001 à 17:16:50
je dirai que ça a des chances de ne pas marcher, mais bon ..., ça n'engage que moi. normalement, je dirai plutôt que dans le where il y a la clé de la table, donc pas la peine de la sélectionner dans returning. si c'est pour mettre à jour plusieurs lignes, je pense pas que ça marchera, il me semble que le sql ne prend pas en charge les tableaux.
Marsh Posté le 23-05-2001 à 17:21:39
Je m'explique
je ne cherches pas a ce que ca marche !
Je cherche a faire les API qui vont le faire marcher...
Il faut donc que comprenne comment ca marche...
Oracle me dit qu'il y a sept lignes (il y en a sept dans ma table), prends deux adresses pour me renvoyer des valeurs et ne m'en renvoie qu'une... je ne comprend rien
voir http://forum.hardware.fr/sqlforum/ [...] ache=cache
Marsh Posté le 23-05-2001 à 17:27:55
ben oui, les variables ne sont pas des tableaux, c'est pour cela qu'il n'y a qu'une seule valeur. c'est à partir de quel langage que tu veux faire ça ???
Marsh Posté le 23-05-2001 à 17:31:04
C/C++ et OCI...
dans la doc ils font une allocation dynamique...
moi j'ai que une valeur pour name et des valuers fausses pour numb....
Marsh Posté le 23-05-2001 à 17:31:59
En direct de la doc oracle :
(langage PL/SQL - ce n'est pas du SQL) :
Use the RETURNING Clause
Often, applications need information about the row affected by a SQL operation, for example, to generate a report or take a subsequent action. The INSERT, UPDATE, and DELETE
statements can include a RETURNING clause, which returns column values from the affected row into PL/SQL variables or host variables. This eliminates the need to SELECT the row after
an insert or update, or before a delete. As a result, fewer network round trips, less server CPU time, fewer cursors, and less server memory are required.
In the following example, you update the salary of an employee and at the same time retrieve the employee's name and new salary into PL/SQL variables.
PROCEDURE update_salary (emp_id NUMBER) IS
name VARCHAR2(15);
new_sal NUMBER;
BEGIN
UPDATE emp SET sal = sal * 1.1
WHERE empno = emp_id
RETURNING ename, sal INTO name, new_sal;
================================
donc tu dois récupérer 0 et non 1 comme valeur dans :numb
Marsh Posté le 23-05-2001 à 17:33:54
zejeanmi a écrit a écrit : En direct de la doc oracle : (langage PL/SQL - ce n'est pas du SQL) : Use the RETURNING Clause Often, applications need information about the row affected by a SQL operation, for example, to generate a report or take a subsequent action. The INSERT, UPDATE, and DELETE statements can include a RETURNING clause, which returns column values from the affected row into PL/SQL variables or host variables. This eliminates the need to SELECT the row after an insert or update, or before a delete. As a result, fewer network round trips, less server CPU time, fewer cursors, and less server memory are required. In the following example, you update the salary of an employee and at the same time retrieve the employee's name and new salary into PL/SQL variables. PROCEDURE update_salary (emp_id NUMBER) IS name VARCHAR2(15); new_sal NUMBER; BEGIN UPDATE emp SET sal = sal * 1.1 WHERE empno = emp_id RETURNING ename, sal INTO name, new_sal; ================================ donc tu dois récupérer 0 et non 1 comme valeur dans :numb |
J'ai plutot 489526774135, c'est normal ?
Marsh Posté le 23-05-2001 à 17:36:06
doit y'avoir des problèmes dans le passage des paramètres.
ne vaut t-il pas mieux passer par un curseur ???
en pro*C on peut le faire en sélectionnant dans un tableau, mais en sql, les tableaux ...
Marsh Posté le 23-05-2001 à 17:37:38
ddr555 a écrit a écrit : doit y'avoir des problèmes dans le passage des paramètres. ne vaut t-il pas mieux passer par un curseur ??? en pro*C on peut le faire en sélectionnant dans un tableau, mais en sql, les tableaux ... |
C'est un test pour une API, dans la realite je ne connais pas la requete...
Marsh Posté le 23-05-2001 à 17:46:12
en fait j'ai peut être (sûrement) mal compris
UPDATE curious SET numb = numb-1 WHERE numb = 1 RETURNING name,numb INTO name,numb
marche comme je l'ai dis (on obtient bien 0)
par contre
UPDATE curious SET numb = numb-1 WHERE numb = 1 RETURNING name,numb INTO :name,:numb
non, car :name et :numb sont des variables de lien
(j'en sais pas plus pour l'instant)
Marsh Posté le 23-05-2001 à 18:32:54
mais ce code là est dans une prod stock ??? si ça retourne rien, c'est normal, il faut passer les arguments en IN OUT dans l'appel de la procédure.
Marsh Posté le 23-05-2001 à 16:49:58
j'ai une requete SQL
UPDATE curious SET numb = numb-1 WHERE numb = 1 RETURNING name,numb INTO :name,:numb
que dois-je obtenir dans name et numb
la table est definie comme suit :
CREATE TABLE curious(name CHAR(25), numb NUMBER)