Est-ce en utilisant SELECT dans une fonction de table PL / SQL permis pipe-line?

Question

Les documents pour les fonctions canalisées disent que DML n'est pas autorisé quand ils sont utilisés dans une instruction SQL (généralement un SELECT), et dans la plupart des exemples les fonctions canalisées sont utilisées pour la génération de données ou la transformation (accepter un custor comme paramètre), mais pas d'émettre des déclarations DML.

Maintenant, techniquement, il est possible d'utiliser SELECTs sans aucune erreur d'Oracle ( ORA 14551 ne se produira pas). Cependant, j'ai des expériences de comportement étrange reproductible de la sélection; même si PRAGMA AUTONOMOUS_TRANSACTION est pas utilisé, les lignes récupérées par l'SELECT semblent pas en prenant toujours la transaction locale actuelle en compte, qui se sent comme un bug pour moi. Plus inquiétant encore est le fait que, lors de l'utilisation d'une transaction distribuée (par exemple via ORAMTS au lieu d'une transaction locale), la transaction est utilisée.

Modifier Il se trouve, l'effet étrange semble lié à certaines des déclarations dans la requête, qui travaillent parfois et parfois pas (selon l'humeur actuelle de l'optimiseur Oracle, au moins en 10g). Dans certains cas, je reçois un ORA-32036, puis de nouveau, il ne se produit pas, sans changer le code du tout. Maintenant, il semble que les requêtes qui échouent parfois avec l'ORA-32036 sont celles qui échouent également d'utiliser la transaction correcte, et il peut être sans rapport avec la fonction pipe-line.

Alors mes questions spécifiques sont:

• Y at-il, de préférence officielle, déclaration indiquant si SELECTs dans les fonctions de table sont autorisés et canalisées ce que leur contexte transactionnel est?

• Y at-il une autre façon de modularisation requêtes couramment utilisées qui peuvent être utilisés dans les instructions SQL (comme fonctions de table peut avec TABLE())?

• Quelqu'un at-il aussi connu un tel comportement et ne sait peut-être plus à ce sujet? Je l'ai regardé dans Metalink, mais malheureusement je ne trouve rien de précis sur le sujet.

Answer 1

1. habituellement des restrictions DML seule modification de préoccupation (UPDATE, DELETE ...) déclarations afin SELECT devrait être OK. Je vais essayer de trouver une déclaration spécifique d'Oracle.

2. Vues serait votre premier outil de requêtes modularisation couramment utilisés.

3. Les fonctions ont un inconvénient sur une vue: si elles sont appelées à un autre SELECT ils ne sont pas exécutées au même point en temps comme la principale SELECT. Chaque appel à une commande SELECT est cohérente, mais depuis le SELECT sont dans le code de fonction et non dans la principale SQL vous pouvez renvoyer des résultats incohérents. Ce n'est pas possible avec des vues et des sous-select. Si une grande déclaration appeler une vue de la vue est construit au même point en temps que la requête principale

Mise à jour : en ce qui concerne vos commentaires sur les requêtes paramétrées

Vous pouvez créer des vues paramétrées, c'est des vues qui dépendent de variables définies avant l'exécution. Voici un exemple sur AskTom montrant comment vous pouvez le faire avec userenv('client_info') ou dbms_session.set_context.