Procedure oracle 10

bonjour tout le monde,

Aujourd'hui je viens avec un problème qui me fatigue énormément, voilà je veut faire une base de données en oracle 10g, après que je finis de créer les tables, je me suis dis de faire des procédures qui vont me permettre de renseigner les tables, mais voilà ce qu'on me dit si je fais une procédure:

Citation:

---

"Procédure crée avec erreur de compilation"

---

exemple

Code:

---

1 2 3 4 5

create procedure(parametres) IS BEGIN INSERT INTO table(champs) values(parametres); end; /

---

Merci de me venir en aide

Le plus simple dans ce cas, c'est de consulter la vue USER_ERRORS pour avoir le détail des erreurs.
En revanche, fournir une espèce de pseudo-code comme vous l'avez fait ne sert à rien. Etant donné que les erreurs de compilation sont dues soit à une syntaxe incorrecte, soit à des objets inexistants, seul le code réel permet de mettre le doigt sur les problèmes.

Pour faire tel instruction dans une procédure, utilise

Code:

---

execute immediate...

---

comme suite

Code:

---

1 2 3 4 5 6

create procedure test IS BEGIN execute immediate 'INSERT INTO table(champs) values(parametres)'; commit; end;

---

Citation:

---

Envoyé par islamov2000

Pour faire tel instructiondansune procédure, utilise...

---

Dans la compétition "comment écrire le pire du code en PL" votre exemple attire l'attention.

@mnitu. je ne comprend pas pourquoi ton commentaire. si tu as voulu parler de create procedure(parametre) je n'ai pas fait attention, et si tu veux parlé du principe, où est le problème.

Votre exemple de deux lignes de code (si on ignorer les lignes inévitables à la définition de la procédure) montre deux mauvaises habitudes de programmation :

1. employer le sql dynamique inutilement
2. faire commit dans une procédure

Donc deux sur deux ce n’est pas si mal !

Le problème avec votre code, c'est qu'il n'y a aucun besoin d'utiliser du SQL dynamique (EXECUTE IMMEDIATE) pour faire un simple INSERT.

Le SQL dynamique s'impose quand :

• la requête est construite durant l'exécution (par exemple, on ne sait pas à l'avance sur quelles tables elle va porter)
• on veut effectuer une commande du LDD (CREATE, ALTER, DROP...)

Il faut préciser que si l'inconnue porte seulement sur la valeur de comparaison dans un prédicat, il n'y a pas besoin de SQL dynamique, car une simple variable suffit.

Code:

---

1 2	... WHERE matricule = v_mat

---

Le faite de poster tel exemple est de montrer la faisabilité de mettre

Code:

---

INSERT INTO...

---

avec SQL dynamique. rien d'autre que ça

Citation:

---

Envoyé par islamov2000

Le faite de poster tel exemple est de montrer la faisabilité de mettre

Code:

---

INSERT INTO...

---

avec SQL dynamique. rien d'autre que ça

---

Votre solution était précédée par "Pour faire tel instruction dans une procédure, utilise", ce qui signifie que selon vous, le SQL dynamique est nécessaire pour répondre au besoin.

Maintenant, si vous préférez quitter le terrain de la technique pour entrer dans celui de la mauvaise foi, je me retire de cette discussion.

Mon intension de

Citation:

---

"Pour faire tel instruction dans une procédure, utilise"

---

est juste pour répondre à la préoccupation de barry mouctar qui a voulu faire un

Code:

---

INSERT INTO..

---

sous le code de PL/SQL, Pomalaix.

Citation:

---

Envoyé par islamov2000

Mon intension de est juste pour répondre à la préoccupation de barry mouctar qui a voulu faire un INSERT INTO.. sous le code de PL/SQL

---

Donc vous pensez qu'il est nécessaire d'utiliser le sql dynamique pour faire un insert dans du PL/SQL.

Lisez peut être Procédures, Fonctions et paquetages du guide du forum pour vous rendre compte que c'est inutile.

Bonjour,

vous avez largement expliqué pourquoi le sql dynamique était ici contre productif.

Par contre, personne n'a réagi à :

Citation:

---

Envoyé par mnitu

faire commit dans une procédure

---

Pouvez vous expliquer en quoi faire des commit dans une procédure est une mauvaise habitude de programmation (ou donner un lien)

Citation:

---

Envoyé par A.Herobic

...Pouvez vous expliquer en quoi faire des commit dans une procédure est une mauvaise habitude de programmation (ou donner un lien)

---

Une procédure constitue souvent une étape parmi d'autres au sein d'une transaction. Si la procédure comporte une fin de transaction sans que l'appelant en ait conscience, alors on vient de créer une bogue, car le découpage transactionnel n'est plus celui qu'on pensait.

Code:

---

1 2 3 4 5

insert update procedure_avec_commit delete rollback

---

Il est préférable de ne pas introduire de COMMIT/ROLLBACK dans une procédure, et de laisser à l'appelant, au niveau supérieur, la responsabilité de finaliser la transaction.
La procédure est alors vue comme une boîte noire, qui effectue le traitement demandé, mais sans interférer sur le découpage transactionnel.

On peut tout à fait imaginer une norme de développement dans l'entreprise qui interdise toute commande provoquant une fin de transaction dans les procédures.
Je serais pour ma part moins extrémiste, en me contentant d'une norme de nommage qui indique clairement si la procédure fait un COMMIT.
Par exemple, j'appellerais ma procédure p_cloture_mens_CMT, le suffixe CMT signifiant qu'elle provoque un COMMIT.

Commit implique la fin d’une transaction mais la fin d’une procédure ne vaut pas forcement la fin de la transaction. Autrement dit une procédure ne sait rien des frontières de la transaction à laquelle elle participe donc en conséquence elle n’a aucun raison de terminer une transaction. C’est au programme appelant de la procédure de décider de terminer la transaction.

Comme d’habitude il existe (au moins) une exception notable qui est celle d’une procédure en transaction autonome.

Citation:

---

Envoyé par Pomalaix

...
Je serais pour ma part moins extrémiste, en me contentant d'une norme de nommage qui indique clairement si la procédure fait un COMMIT.
Par exemple, j'appellerais ma procédure p_cloture_mens_CMT, le suffixe CMT signifiant qu'elle provoque un COMMIT.

---

Ça n’a rien à voir avec quelconque extrémisme mais c’est plutôt la suite logique de la réutilisation du code induite par des besoins parfois difficile à anticiper.

Bref, juste une petite histoire sur la dernière fois quand j’ai ajouté une instruction COMMIT (il y a quelques années) dans une procédure non-autonome. J'ai remplacé un traitement batch écrit dans un vieux langage d’Oracle, RPT, par un package PL/SQL. Comme ce traitement batch était unitaire et se terminait par un commit j’ai trouvé raisonnable de finir la procédure qui pilote le traitement par commit. Trois mois plus tard un nouveau besoin est arrivé pour intégrer ce même traitement dans un autre dans le cadre d’une demande spécifique ! Et maintenant ce commit si logique avant a commencé à poser un problème !

A la limite si quelqu’un ne peut pas vivre sans faire commit dans une procédure, la meilleure pratique d’après moi, sera de créer :

• Une procédure qui fait le boulot sans commit
• Une deuxième procédure qui ne fait qu’appeler la première pour y ajouter un commit.

Mais je doute sérieusement que j'ai pourrais trouver un vrai besoin à ceci.

Et pourquoi pas spécifier le type de ton paramètre ? :aie: