Discussion :

[ze_patoche]

Bonjour

Dans le cadre d'une migration de SQL Server 7.0 vers Oracle 9i2, je suis confronté à un problème sur des triggers.
Sous SQL Server, un trigger sur une table va utiliser un curseur sur cette même table, et va même jusqu'à y effacer des lignes. Sous Oracle, à partir du moment où on est dans le trigger, c'est qu'on a modifié les données de la table... donc la table est dite "en mutation" et toute opération de sélection ou de suppression est interdite...
Comment puis-je faire pour contourner le problème?

[ze_patoche]

On la refait rapidement:
Je me suis un peu emballé sur la suppression de ligne dans le trigger-même... ^_^;
En revanche, il fait bien un select par le biais d'un curseur...
Le problème reste donc entier

[Médiat]

En revanche, il fait bien un select par le biais d'un curseur...

SELECT dans la table même ou dans une autre table (deleted, inserted ou updated) ?

[ze_patoche]

Oui, select dans la table-même.

CREATE TRIGGER my_trigger ON my_table
FOR INSERT, UPDATE
AS
...
DECLARE my_cursor CURSOR SCROLL FOR
SELECT champs1
FROM my_table
...

Quelque chose dans ce gout-là...
En fait il y a bien une boucle principale sur un curseur sur la table inserted, mais il n'y a pas de problème de ce côté.

[McM]

Utilise la recherche de "mutating table" sur le forum.
Ca a déja été posé comme question.

[ze_patoche]

Super, merci pour cette info.
A présent je vois mieux le problème, mais je suis encore un peu coincé sur mon cas.
L'idéal serait de faire de mon curseur une transaction autonome (puisqu'il ne fait qu'un select dans la table), mais il semblerait qu'on ne puisse faire ça qu'avec des "objets complets" type trigger, procédures, etc...

[orafrance]

http://sgbd.developpez.com/oracle/ora-04091/

[ze_patoche]

Merci pour le lien, mais la recherche sur les tables mutantes m'avait mené aussi à cet article
Je pensais m'en sortir avec des triggers qui faisaient appel à des procédures en transaction autonomes, mais je commence à en douter:
Il y a 5 triggers qui s'enchainent les uns à la suite des autres.
Je vais essayer de schematiser un peu la problématique:

J'ai:
- une table d'articles
- une table de couts des articles
- une table de nomenclatures qui regroupent des listes d'articles
- une table d'historique des nomenclatures

L'idée générale est la suivante:
Dans le cas d'une modification d'un article, la table de cout d'article est modifiée (par trigger donc). Lors de la modification de la table des couts, la table des nomenclatures est mise à jour (toujours par trigger), avec une partie des informations contenues dans la table des articles (qui est donc toujours en mutation suite au 1er trigger).
Et au cas où j'aurais réussi à contourner ce problème, il faut ensuite créer l'historique des nomenclatures en parcourant (ici par curseur) la table des nomenclatures (elle aussi toujours en mutation).

En fait ça continue comme ça sur 2-3 générations par la suite... C'est un peu pour ça que je cherchais une solution générale plutôt que de changer chacun des traitements... ^_^;
Ce qui m'étonne, c'est que tout ceci fonctionne sans problème sous SQL Server, et qu'Oracle ne semble pas pouvoir fonctionner de la même façon.
J'ai essayé diverses options, les triggers en AFTER, externaliser les traitements qui pointent sur les tables mutantes dans des procédures en transactions autonomes (ce qui semble ralentir CONSIDERABLEMENT le traitement)...

A présent, j'en suis à me demander si je jette le serveur Oracle par la fenêtre ou si je me recycle dans la boulangerie... ^^;