Tabela temporária do servidor SQL usando # - é acessível apenas pela consulta contida para várias conexões com o mesmo login?

Objetos temporários locais são separados por Session. Se você tiver duas consultas em execução simultaneamente, elas são claramente duas sessões completamente separadas e você não precisa se preocupar. O Login não importa. E se você estiver usando o pool de conexões, isso também não importará. Objetos temporários locais (tabelas com mais frequência, mas também procedimentos armazenados) estão protegidos de serem vistos por outras sessões.

Embora seu código tenha um nome único e comum para os objetos temporários locais, o SQL Server anexa uma string exclusiva a cada nome de objeto por cada sessão (e, se necessário, por cada subprocesso) para mantê-los separados. Você pode ver isso executando as seguintes consultas no SSMS:

CREATE TABLE #T (Col1 INT)

SELECT * FROM tempdb.sys.tables WHERE [name] LIKE N'#T%';

Você verá algo como o seguinte para o nome (removi a maioria dos sublinhados do meio do nome para evitar a necessidade de rolar aqui):

#T_______________00000000001F

Em seguida, sem fechar essa guia de consulta, abra uma nova guia de consulta e cole essas mesmas 2 consultas e execute-as. Agora você deve ver algo como o seguinte:

#T_______________00000000001F
#T_______________000000000020

Portanto, cada vez que seu código fizer referência a #T, o SQL Server o traduzirá para o nome adequado com base na sessão. Tudo é tratado auto-magicamente :-).

Para ilustrar este ponto. Trabalhei em sistemas altamente transacionais (milhares de transações por segundo) e eram aplicativos web SaaS (Software as a Service) rodando 24 horas por dia, 7 dias por semana. Todo o código T-SQL estava em Stored Procedures (ou seja: mesmo nome de tabela temporária local para cada execução desse código) e fizemos um bom uso das tabelas temporárias locais. Sendo um aplicativo da web, o Login foi o mesmo em quase todas as conexões e definitivamente usamos o pool de conexões. Nunca tivemos problemas para indicar qualquer acesso entre sessões de objetos temporários locais com o mesmo nome. E, francamente, ficaríamos chocados e usaríamos nosso contrato de suporte com a Microsoft para consertá-lo se isso acontecesse.

Pontos adicionais a serem lembrados em relação às tabelas temporárias locais:

1. Embora seus nomes sejam exclusivos, seus objetos dependentes não são. Você não pode criar Triggers ou Chaves Estrangeiras em tabelas temporárias, portanto, trata-se realmente de Chaves Primárias, Restrições de Verificação e Restrições Padrão. Isso significa que nomear uma Chave Primária #PK_#Tnão a torna um nome exclusivo com um ID exclusivo de bastidores anexado ao nome. Se você tentar isso, obterá "Não é possível criar objeto. O objeto já existe". erros (bem, assumindo várias execuções simultâneas neste mesmo código). Portanto, se você precisar de qualquer um desses 3 tipos de objeto para uma tabela temporária local, crie o(s) objeto(s) dependente(s) embutido(s) para que eles obtenham nomes gerados pelo sistema que serão exclusivos e não entrarão em conflito entre as Sessões.

   Você não precisa se preocupar com nomes de índice, pois eles já estão separados por [object_id].

2. Dado que você obtém "Não é possível criar objeto. O objeto já existe". erros ao criar objetos dependentes nomeados, isso traz um bom ponto que é mais frequentemente esquecido em relação a essa questão de "os objetos temporários locais são completamente isolados por sessão": Se as tabelas temporárias locais pudessem ser vistas por outras sessões, a CREATE TABLEinstrução obteria um erro, certo?

3. Uma nuance de tabelas temporárias locais (que também é um contraponto solto para #2 acima) é que se você referenciar uma tabela temporária local em um subprocesso (ou seja, EXEC) que foi criado antes do início desse subprocesso, ela poder ver (e até modificar) essa tabela temporária local. NO ENTANTO, se esse subprocesso criar outra tabela temporária com o mesmo nome, haverá dois objetos, com IDs exclusivos separados anexados ao final, que podem ser acessados ​​por meio do nome abreviado. Lembro-me de ler em algum lugar que não há garantia de que a referência#nameno subprocesso sempre resolverá para a versão desse objeto que foi criado no subprocesso. Portanto, é melhor ter alguma exclusividade de nomes de tabelas temporárias locais entre Stored Procedures que tenham qualquer possibilidade de serem executadas em uma cadeia de chamadas de Stored Procedure aninhadas.