Vindo da Oracle, descobri que o SSMS se conecta um pouco diferente do SQL Developer da Oracle. Oracle, você clica em UMA conexão e, em seguida, todas as guias que você abre, usam essa conexão. O SSMS cria uma conexão/instância completamente nova para cada janela/guia que eu abro. Eu não quero isso . DOIS aborrecimentos me vêm à mente com esse comportamento que estou tentando contornar.
- Veja o efeito do script antes do COMMIT em outra janela
Eu quero poder executar um script em uma janela... e em outra janela ter a capacidade de consultar os dados não confirmados para simplesmente visualizar os resultados... Atualmente tenho que usar a MESMA Janela em que executei o script para simplesmente VER o efeito. (Os botões Commit/Rollback vêm à mente - Oracle, às vezes sinto sua falta).
- Visualize os dados armazenados em #TempTable de outra janela
Estou criando uma #TempTable usando um script... mas quero consultar seus dados de outra janela. Atualmente quando abro outra janela (ao contrário do SQL Developer da Oracle) ela abre a janela usando uma nova conexão/instância. Como faço para consultar os dados em #TempTable de outra janela em vez da janela em que executei o script?
O acima é apenas por razões organizacionais ... é TÃO chato executar um script ... e, a partir dessa mesma guia, tenho que escrever outro código quando não quero editar / adicionar nenhum outro código ao página que contém o script que executei.
Se eu estiver fazendo algo errado ou faltando algum ponto, por favor me avise.
Você não está perdendo nada. O SSMS sempre tem uma sessão separada por guia.
No SSMS o comando Executar (F5,Ctrl-e), sempre executa o texto realçado na janela de consulta, se houver.
E assim, a maneira normal de as pessoas usarem as janelas de consulta do SSMS aqui é destacar seções de código a serem executadas, geralmente separando o script principal dos bits de teste/depuração usando comentários de várias linhas.
Por exemplo, ao desenvolver um procedimento armazenado, a janela de consulta pode se parecer com:
Em seguida, execute todo o script para recriar o proc, destaque as linhas de teste e execute para testá-lo.
Você pode usar dicas de tabela como WITH (NOLOCK) ou WITH (READUNCOMMITTED) para realizar leituras sujas de dados não confirmados entre duas janelas no SSMS.
Você pode usar tabelas temporárias globais (##Table em vez de #Table) para consultar tabelas temporárias entre sessões. Observe que você deve criar a tabela temporária como uma tabela temporária global para começar.
Uma maneira simples é escrever seu script inteiro, incluindo as consultas para verificar/testar suas alterações de dados e, na verdade, destacar as partes individuais que você deseja executar e executá-las.
Pegue o exemplo de código abaixo. Quero inserir dois registros em uma tabela, validar o resultado e depois confirmar se estiver satisfeito ou reverter se não:
Eu colocaria todo o código em uma única janela, destacaria as linhas 1-5 e pressionaria Execute/F5. Os dados são inseridos, mas não confirmados, então destaco a linha 7 e clico em Execute/F5 e verifico os resultados. Se estou feliz, destaco a linha 9 e clico em Execute/F5 para confirmar as alterações ou se quiser reverter, destaco a linha 11 e clico em Execute/F5.
Além disso, observe que, se IMPLICIT_TRANSACTIONS estiver OFF (padrão), sua sessão estará basicamente usando 'autocommit', o que significa que sem um BEGIN TRANSACTION explícito, a instrução INSERT seria confirmada automaticamente.