Não há boas maneiras de fazer isso. É uma limitação de procedimentos armazenados. Suas opções são:
-
Mude o procedimento para uma Função definida pelo usuário . Em todo o mundo, hoje, as pessoas estão fazendo procedimentos armazenados que deveriam ser funções. É uma questão de educação. Você situação é um bom exemplo do porquê. Se o seu procedimento fosse uma UDF, você poderia fazer o seguinte, exatamente como você pensa intuitivamente que deveria ser capaz de:
SELECT * FROM udf_who2() WHERE login='bmccormack' -
Se você realmente não pode tocar em seu procedimento e deve ter isso feito em sql, então você terá que ficar descolado. Faça outro procedimento armazenado para encapsular seu procedimento original. Dentro de seu novo procedimento, chame seu procedimento existente e coloque os valores em uma tabela temporária, depois execute uma consulta nessa tabela com o filtro desejado e retorne esse resultado para o mundo exterior.
A partir do SQL Server 2005, as funções definidas pelo usuário são como você encapsula a recuperação de dados. Stored Procedures, juntamente com Views, são ferramentas especiais para uso em situações particulares. Ambos são muito úteis na hora certa, mas não a primeira escolha. Alguns podem pensar que o exemplo acima (A) obtém todos os resultados da função e, em seguida, (B) filtra esse conjunto de resultados, como uma subconsulta. Este não é o caso . O SQL Server 2005+ otimiza essa consulta; se houver um índice em
login , você não verá uma verificação de tabela no plano de execução da consulta; muito eficiente. Editar :devo acrescentar que as entranhas de uma UDF são semelhantes às de um SP. Se está mexendo com a lógica do SP que você deseja evitar, você ainda pode alterá-lo para uma função. Várias vezes eu peguei um código de procedimentos grande e assustador que eu não queria ter que entender e o transferi com sucesso para uma função. O único problema será se o procedimento modificar qualquer coisa além de retornar resultados; UDFs não podem modificar dados no banco de dados.
