Non ci sono buoni modi per farlo. È una limitazione delle stored procedure. Le tue opzioni sono:
-
Passare la procedura a una Funzione definita dall'utente . In tutto il mondo, oggi, le persone creano procedure archiviate che dovrebbero essere funzioni. È una questione di educazione. La tua situazione è un buon esempio del perché. Se la tua procedura fosse invece una UDF, potresti semplicemente fare quanto segue, esattamente come pensi intuitivamente di dover essere in grado di:
SELECT * FROM udf_who2() WHERE login='bmccormack' -
Se proprio non puoi toccare la tua procedura, e devi fallo in sql, quindi dovrai diventare funky. Crea un'altra stored procedure per eseguire il wrapping della procedura originale. All'interno della tua nuova procedura chiama la tua procedura esistente e inserisci i valori in una tabella temporanea, quindi esegue una query su quella tabella con il filtro desiderato e restituisce quel risultato al mondo esterno.
A partire da SQL Server 2005, le funzioni definite dall'utente consentono di incapsulare il recupero dei dati. Le stored procedure, insieme alle viste, sono strumenti speciali da utilizzare in situazioni particolari. Sono entrambi molto utili al momento giusto, ma non la prima scelta. Alcuni potrebbero pensare che l'esempio sopra (A) ottenga tutti i risultati della funzione e quindi (B) filtri su quel set di risultati, come una sottoquery. Non è così . SQL Server 2005+ ottimizza tale query; se c'è un indice su login , non viene visualizzata una scansione della tabella nel piano di esecuzione della query; molto efficiente.
Modifica :Aggiungo che le viscere di un UDF sono simili a quelle di un SP. Se sta pasticciando con la logica dell'SP che vuoi evitare, puoi comunque cambiarlo in una funzione. Diverse volte ho preso codice di procedure grandi e spaventose che non volevo dover capire e l'ho trasferito con successo a una funzione. L'unico problema sarà se la procedura modifica qualsiasi cosa oltre a restituire risultati; Le UDF non possono modificare i dati nel db.
