Discussion :

[gregb34]

Bonjour,

Sous Oracle, j'ai cette procedure stockée :

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
create or replace procedure eleves_infos(id IN INT)
AS
  cursor eleves_infos is 
    SELECT eleve_nom,eleve_prenom
    FROM BG_eleves
    WHERE eleve_id = id;
 
   infos_nom varchar(20);
   infos_prenom varchar(20);
BEGIN
  open eleves_infos;
  fetch eleves_infos into infos_nom,infos_prenom;
END;
/
show errors;

Elle se crée parfaitement mais quand je l'appele avec call, elle me renvoie rien alors qu'elle devrait.

J'ai un doute sur le OPEN et le FETCH. Il faut rajouter qqu chose ?

MERCI de votre aide

[pifor]

C'est normal, une procédure n'est pas une fonction: une procédure ne retourne rien . Pour avoir des exemples de fonctions retournant des curseurs, voir par exemple http://www.developpez.net/forums/sho...d.php?t=139679

[gregb34]

OKI je vois, en fait, faut creer une fonction...

en fait, ma procedure est la suivante, celle que j'ai posté s'etait un exemple simple.

la vrai procédure (en fait fonction) est celle-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
create or replace procedure heures_p_reste(eleve_id IN INT)
AS
  cursor heures_p_reste is 
    SELECT SUM(BG_FORFAIT.FORFAIT_NBRE_HR_COND),MIN(BG_FORFAIT.FORFAIT_NBRE_HR_COND)
    FROM BG_FORFAIT,BG_POSSEDE
    WHERE BG_FORFAIT.FORFAIT_ID=BG_POSSEDE.FORFAIT_ID
    AND BG_POSSEDE.ELEVE_ID=eleve_id;
 
   h_sum integer;
   h_min integer;
BEGIN
  open heures_p_reste;
  fetch

Il faut donc, que je crée une fonction pour utiliser h_sum et h_min dans mon application... C'est bien ca ?

[dyvim]

Elle se crée parfaitement mais quand je l'appele avec call, elle me renvoie rien alors qu'elle devrait.

Pour l'instant ta procédure fait 2 chose:
- créer un curseur
- affecter certaines champs de la première ligne du curseur dans des variables (et encore la deuxième version ne le fait pas)
Elle ne risque pas de te rendre quelque chose puisque tu ne lui demandes rien d'autre.

J'ai un doute sur le OPEN et le FETCH. Il faut rajouter qqu chose ?

En général un curseur se parcoure en boucle avec un FOR et/ou un LOOP de façon à ne pas traiter que la première ligne.

D'une façon générale une procédure est là pour effectuer un traitement (UPDATE , DELETE ou INSERT), alors qu'une fonction doit retourner (instruction RETURN) quelque chose (une variable).

La vraie question est: Que veux tu faire?

Si tu veux récupérer le résultat d'un SELECT (celui de ton curseur) une procédure est à priori inutile, utilise juste le SELECT du SQL.

[gregb34]

En fait, je cherche a effectuer les requetes necessitant des ressources improtantes par le serveur : SUM, Requetes imbriquées... On m'a dit de faire des procédures stockées. Apprement, derriere cela, il y a de nombreux concepts, les vues...

Alors je sais pas ce que vous pouvez me conseiller de faire ?

[dyvim]

Une règle qui vient de chez Oracle...
"Si tu peux le faire en SQL fait le en SQL,
si ca ne suffit pas utilise le PL/SQL,
si ca ne suffit toujours pas (là ca devient plus rare), utilise le C ou Java en procédures stockées"


Pourquoi utiliser une procédure stockée:
pour effectuer un traitement un peu complexe et répété régulièrement si possible (sinon on fait juste un bloc PL/SQL qu'on lance une seule fois)

Pourquoi utiliser une vue:
pour ne pas avoir à réécrire toujours le même SELECT.
(et éventuellement si tu veux optimiser ton accès aux données tu fais une vue matérialisée)

[gregb34]

Des select qu ise repete, j'en ai pas... mais j'ai quelques requetes imbriqués + des requetes avec pas mal de jointures, des MIN, des MAX...

Et je sais pas ou les caller. Un simple ISERT, je vois pas comment ca peux etre complexe...

[dyvim]

Des select qu ise repete, j'en ai pas... mais j'ai quelques requetes imbriqués + des requetes avec pas mal de jointures, des MIN, des MAX...

Et je sais pas ou les caller. Un simple ISERT, je vois pas comment ca peux etre complexe...

Tu fais un insert basé sur tes "requetes imbriqués , requetes avec pas mal de jointures, des MIN, des MAX..." ??

Si c'est çà alors fais une procédure stockée oui...
Ceci dit le fait de stocker ton traitement ne le rendra pas forcément plus rapide.

Mais ce n'est peut être pas la peine de faire un curseur.

[gregb34]

Justement, je n'ai pas de INSERT "complexe" ... ou autre UPDATE

J'ai juste qq SELECT un peu complexe. C'est tout. Et on m'oblige à utiliser des "procedures stockées" (Je passe le BTS)

J'ai pas envie de les placer n'importe comment, sachant qu'on va me demander de les justifier.

Voila

[dyvim]

Excuse moi mais peux tu nous dire EXACTEMENT ce qui t'es demandé parce que là je ne comprends plus.

D'après ce que tu me dis les procédures stockées ne servent à rien (sauf s'il faut stocker leur résultat dans une ou plusieurs table).
Je ne comprends vraiment pas pourquoi tu es obligé de les utiliser.

[gregb34]

Alors, c'est simple.

J'ai actuellement une application faite sous Delphi qui se connecte a une base de donnée Oracle.
Toutes mes requetes, sont definies dans l'application Delphi (Client)

L'application comporte des requetes "simples".

Il y a malgré tout quelques requetes SELECT (uniquement des SELECT), un peu plus complexes.

On me demande de mettres les requetes en procédures stockée. Faut que je fasse un choix, puisque toutes les requetes n'ont pas un interet majeures a êtres mise en procédures stockées.

D'apres ce que tu me dis, seules les INSERT, UPDATE.. complexes on un interet à être mises en procédures stockées.

Mais en attendant faut que je stocke des requetes cotés serveurs

je suis perdu, a vrai dire.

Mon prof que je ne peux pas contacter, m'a dit cela :

il y a des requêtes qui n'ont pas de besoin impératif d'être mises
sous forme de procédures stockées: celles qui ne font que très peu de
calculs sur les données, et qui ne fourniront qu'(une matière première
à un listing brut par exemple. Un select * sous forme de procédure
stockée n'a aucun intéret ... puisque de toute façon c'est le même
résultat (la même quantité de données) qui sera renvoyée au client
dans les deux cas (procédure stockée ou non).

Les procédures stockées prennent l'avantage lorsqu'il faut réaliser
des calculs sur les données, car le SQL présente l'intéret d'avoir des
instructions de calcul (min, max, sum, etc) sur les champs, ce qui
évite par exemple de faire un select * sur une table, de récupérer les
réponses du serveur, puis de faire les calculs sur les résultats au
niveau du client.

donc non, tout ne doit pas être en procédure stocké, il faut qu'il y
ai un intéret (décharger le client quand c'est possible).

Partant de la, je cherche à mettre les requetes SELECT MAX() .. et requtes imbriqués en procédures stockées. Mais apparement tu me dis que ca concerne que les INSERT et UPDATE.

J'essaye de comprendre. (désolé).

En tout cas, merci de ta patience jusqu'a présent.

PS : Je suis obligé d'en utiliser car cette application est destiné a mon examen du BTS, et ils exigent des procédures stockées et des trigguers (pour les trigguers, je vois l'interet).

[abdelelomari]

C'est normal, une procédure n'est pas une fonction: une procédure ne retourne rien . Pour avoir des exemples de fonctions retournant des curseurs, voir par exemple http://www.developpez.net/forums/sho...d.php?t=139679

Une procédure stockée peut retourner tous les paramètres OUT ou INOUT qui lui sont passés ! Non ?

[SheikYerbouti]

Effectivement, une procédure peut avoir un ou plusieurs de ses argument in IN OUT ou OUT. Il ne s'agit pas vraiment d'un retour dans la mesure ou ces arguments sont transmis dès l'appel.

[gregb34]

Donc pour le problème qui met posé, si je specifie les valeurs de retour de mes MAX et de mes MIN, je peux parfaitement mettre mes requetes dans ce genre de procédure ?
Je vais faire ça je crois. Car je vois pas d'autres solutions à part ca.

[dyvim]

il y a des requêtes qui n'ont pas de besoin impératif d'être mises
sous forme de procédures stockées: celles qui ne font que très peu de
calculs sur les données, et qui ne fourniront qu'(une matière première
à un listing brut par exemple. Un select * sous forme de procédure
stockée n'a aucun intéret ... puisque de toute façon c'est le même
résultat (la même quantité de données) qui sera renvoyée au client
dans les deux cas (procédure stockée ou non).

Les procédures stockées prennent l'avantage lorsqu'il faut réaliser
des calculs sur les données, car le SQL présente l'intéret d'avoir des
instructions de calcul (min, max, sum, etc) sur les champs, ce qui
évite par exemple de faire un select * sur une table, de récupérer les
réponses du serveur, puis de faire les calculs sur les résultats au
niveau du client.

donc non, tout ne doit pas être en procédure stocké, il faut qu'il y
ai un intéret (décharger le client quand c'est possible).

Les propos de ton prof ne sont pas corrects. (pour ne pas dire que c'est n'importe quoi)
Le client en Delphi passe par l'exécution de SqlQuery pour accéder à la base, je ne vois pas pourquoi celle ci lui renverrait toutes les données des tables.
La base Oracle va faire les jointures et le calcul des MIN et/ou MAX, ne retournant que le résultat du SELECT au client.
-> Pas de problème de surcharge du client.
-> Pas besoin de procédures stockées.

Ce que tu peux gagner avec tes procédures stockées c'est:
- un peu de temps d'éxécution (histoire de parsing de requete)
- un peu moins de traffic réseau car un appel de procédure est plus court qu'un select compliqué.
- un peu plus de sécurité car le code du select sera dans la base.

[laurentschneider]

Et on m'oblige à utiliser des "procedures stockées" (Je passe le BTS)

en fait on doit faire tes devoirs, c'est ça?

est-ce que ta question est propre à Oracle, ou bien c'est du RDBMS générique ?

Pour afficher quelque chose en PL/SQL tu peux utiliser le package dbms_output

[dyvim]

Si tu dois absolument faire des "procédures stockées".

Il vaut mieux que tu fasses des fonctions qui te rendent soit des TABLE soit une variable qui correspond à ce que tu veux récupérer (NUMBER ou autre).

pour les appeler fais des

Code :

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

SELECT Ma_fonction(param1,...) FROM DUAL

dans tes Sql_Query de Delphi et affecte le résultat où tu veux

En théorie tu peux aussi passer des variables delphi en paramètre qu'Oracle te rendra avec des nouvelles valeurs.

Code :

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

CALL Ma_procédure (param1,param2,...)

(avec param1 et param2 correspondant à tes variables que tu veux modifier
Mais je ne vois pas bien comment Oracle fera pour modifier tes variables Delphi.