As declarações executadas com sp_executesqlparecem ser geralmente "desvinculadas" do procedimento em que aparecem. Por "bind", quero dizer simplesmente "associado ao objeto de chamada".
O objetivo é simplificar a associação de instruções no Query Store:
select object_name(q.object_id) as [Statement Context]
from sys.query_store_query q
where 1=1
and object_name(q.object_id) like 'This will be the procedure name for ''normal'' statements'
Embora seja possível incorporar comentários nas declarações que aparecerão no query_sql_text, isso parece um pouco mais hack.
Além disso, parece que precisariasp_executesql de alguma forma de ligação de contexto, pois o SQL dinâmico pode acessar tabelas temporárias não globais no escopo circundante: sem uma ligação, como o SQL Server pode garantir a validade e estabilidade do esquema da tabela temporária nos planos criados ?
Eu acho que a incorporação de comentários é atualmente a melhor maneira de distinguir diferentes partes de SQL dinâmico quando visualizados no Query Store / Extended events / Trace - infelizmente.
Eu tive muitos erros de tempo de execução com tabelas dinâmicas sql e temporárias, então não acho que GARANTA a validade e a estabilidade da tabela temporária.
Você pode usar @@nestlevel para ver quantos SPs/funções estão atualmente na pilha de chamadas, mas acho que você deseja mais informações do que isso. Você pode usar error_procedure() - mas apenas em um bloco catch, parece que o que você quer é que a Microsoft adicione uma função current_procedure() ou call_procedure() que informará o nome da rotina atual ou da rotina que chamou esta - talvez adicionar um pedido aqui? :- https://feedback.azure.com/forums/908035-sql-server