Nie ma na to dobrych sposobów. Jest to ograniczenie procedur składowanych. Twoje opcje to:
-
Zmień procedurę na funkcję zdefiniowaną przez użytkownika . Obecnie na całym świecie ludzie tworzą procedury składowane, które powinny być funkcjami. To kwestia edukacji. Twoja sytuacja jest dobrym przykładem dlaczego. Gdyby twoja procedura była zamiast UDF, możesz po prostu wykonać następujące czynności, dokładnie tak, jak intuicyjnie uważasz, że powinieneś być w stanie:
SELECT * FROM udf_who2() WHERE login='bmccormack' -
Jeśli naprawdę nie możesz dotknąć swojej procedury i musisz zrobić to w sql, wtedy będziesz musiał być funky. Utwórz inną procedurę składowaną, aby zawinąć oryginalną procedurę. Wewnątrz nowej procedury wywołaj istniejącą procedurę i umieść wartości w tabeli tymczasowej, a następnie uruchom zapytanie względem tej tabeli z żądanym filtrem i zwróć ten wynik do świata zewnętrznego.
Począwszy od SQL Server 2005, funkcje zdefiniowane przez użytkownika służą do hermetyzacji pobierania danych. Procedury składowane wraz z widokami to specjalistyczne narzędzia do użycia w określonych sytuacjach. Oba są bardzo przydatne we właściwym czasie, ale nie są pierwszym wyborem. Niektórzy mogą pomyśleć, że powyższy przykład (A) pobiera wszystkie wyniki funkcji, a następnie (B) filtruje ten zbiór wyników, jak podzapytanie. Tak nie jest . SQL Server 2005+ optymalizuje to zapytanie; jeśli istnieje indeks na login , nie widzisz skanu tabeli w planie wykonania zapytania; bardzo wydajny.
Edytuj :Powinienem dodać, że wnętrzności UDF są podobne do SP. Jeśli nie zgadza się z logiką SP, którego chcesz uniknąć, nadal możesz zmienić go na funkcję. Kilka razy wziąłem duży, przerażający kod procedur, którego nie chciałem rozumieć, i pomyślnie przeniosłem go do funkcji. Jedynym problemem będzie to, że procedura zmienia się cokolwiek oprócz zwracania wyników; UDF nie mogą modyfikować danych w db.
