Không có cách nào tốt để làm điều đó. Đó là một hạn chế của các thủ tục được lưu trữ. Các tùy chọn của bạn là:
-
Chuyển quy trình sang Chức năng do người dùng xác định . Trên toàn thế giới, ngày nay, mọi người đang tạo ra các thủ tục được lưu trữ mà lẽ ra phải là các hàm. Đó là một vấn đề giáo dục. Tình huống của bạn là một ví dụ điển hình tại sao. Nếu thay vào đó, thủ tục của bạn là UDF, bạn chỉ có thể làm như sau, chính xác như trực giác bạn nghĩ rằng bạn có thể:
SELECT * FROM udf_who2() WHERE login='bmccormack' -
Nếu bạn thực sự không thể chạm vào quy trình của mình và phải hãy làm điều này trong sql, sau đó bạn sẽ phải trở nên sôi nổi. Thực hiện một quy trình được lưu trữ khác để bao bọc quy trình ban đầu của bạn. Bên trong thủ tục mới của bạn, hãy gọi thủ tục hiện có của bạn và đặt các giá trị vào một bảng tạm thời, sau đó chạy một truy vấn đối với bảng đó với bộ lọc bạn muốn và trả kết quả đó ra thế giới bên ngoài.
Bắt đầu với SQL server 2005, các hàm do người dùng định nghĩa là cách bạn đóng gói việc truy xuất dữ liệu. Các thủ tục được lưu trữ, cùng với Chế độ xem, là những công cụ đặc biệt để sử dụng trong các tình huống cụ thể. Cả hai đều rất tiện dụng vào đúng thời điểm, nhưng không phải là lựa chọn đầu tiên. Một số người có thể nghĩ rằng ví dụ trên (A) nhận tất cả các kết quả của hàm và sau đó (B) lọc trên tập kết quả đó, giống như một truy vấn con. Đây không phải là trường hợp . SQL server 2005+ tối ưu hóa truy vấn đó; nếu có chỉ mục trên login , bạn không thấy bảng quét trong kế hoạch thực thi truy vấn; rất hiệu quả.
Chỉnh sửa :Tôi nên nói thêm rằng các phần tử bên trong của UDF tương tự như phần tử của một SP. Nếu nó lộn xộn với logic của SP mà bạn muốn tránh, bạn vẫn có thể thay đổi nó thành một hàm. Một vài lần tôi đã lấy mã quy trình lớn, đáng sợ mà tôi không muốn phải hiểu và chuyển nó thành một hàm. Vấn đề duy nhất sẽ là nếu thủ tục sửa đổi bất cứ điều gì ngoài việc trả về kết quả; UDF không thể sửa đổi dữ liệu trong db.
