Sta usando un SELECT all'interno di una funzione di tabella PL / SQL pipeline ammessi?

Question

La documentazione per le funzioni pipeline dire che DML non è consentita quando vengono utilizzati in un'istruzione SQL (tipicamente un SELECT), e nella maggior parte esempi funzioni pipeline sono utilizzati per la generazione o la trasformazione di dati (accettare un Custor come parametro), ma non l'emissione di eventuali istruzioni DML.

Ora, tecnicamente, è possibile utilizzare SELECT senza alcun errore da Oracle ( ORA 14551 non si verificherà). Tuttavia, ho esperienze strano comportamento riproducibile del select; anche se PRAGMA AUTONOMOUS_TRANSACTION è non in uso, le righe recuperate dalla SELECT sembrano non sempre di prendere la corrente transazione locale in considerazione, che si sente come un insetto per me. Ancora più inquietante è il fatto che, quando si utilizza una transazione distribuita (ad esempio via ORAMTS invece di una transazione locale), la transazione viene utilizzato.

Modifica Come si è visto, lo strano effetto sembra essere legata ad alcune dichiarazioni con le query, che a volte funzionano ea volte no (a seconda dell'umore attuale del ottimizzatore di Oracle, almeno in 10g). In alcuni casi, ho un ORA-32036, poi di nuovo non si verifica, senza modificare il codice a tutti. Ora sembra che le query che a volte non riescono con l'ORA-32036 sono quelli che non riescono anche di utilizzare l'operazione corretta, e può essere correlato alla funzione di pipeline.

Quindi le mie domande specifiche sono:

• C'è qualche, preferibilmente ufficiale, dichiarazione se SELECTs in funzioni del tavolo pipeline sono ammessi e quale sia il loro contesto transazionale è?

• C'è un altro modo di modularizzazione query di uso comune, che può essere utilizzato in istruzioni SQL (proprio come funzioni del tavolo può con TABLE())?

• Qualcuno ha anche sperimentato un comportamento del genere e fa forse saperne di più? Ho guardato in metalink, ma purtroppo non ho trovato nulla di specifico sull'argomento.

Answer 1

1. di solito restrizioni DML unica preoccupazione di modifica (UPDATE, DELETE ...) le dichiarazioni in modo da selezionare deve essere OK. Cercherò di trovare una dichiarazione specifica da Oracle.

2. Vista sarebbe il tuo primo strumento rendere modulare query di uso comune.

3. Funzioni presentano un inconveniente sopra viste: se vengono chiamati da un altro SELEZIONATE non vengono eseguite nello stesso punto nel tempo come il principale SELECT. Ogni chiamata a un SELECT è coerente, ma dal momento che l'istruzione SELECT sono nel codice di funzione e non in SQL principale che si può restituire risultati incoerenti. Questo non è possibile con vista e sub-select:. Se una grande dichiarazione chiamare vista la vista è costruito nello stesso punto nel tempo come la query principale

Aggiorna : per quanto riguarda i suoi commenti su query con parametri

È possibile costruire viste con parametri, cioè punti di vista che dipendono da variabili impostate prima dell'esecuzione. Ecco un esempio su AskTom che mostra come si potrebbe fare con userenv('client_info') o dbms_session.set_context.