Início / dba / Perguntas / 42657
Accepted
jcolebrand
Asked: 2013-05-21 16:34:58 +0800 CST

É "legal" CRIAR e DROP #AlgumaTabela mais de uma vez?

  • 772

Eu tenho meu tipo de código segregado como "blocos coerentes" que posso inserir em um "script de configuração" mais longo repetidamente, e um dos padrões que estou usando é este:

CREATE TABLE #WidgetSetting 
(
    WidgetID bigint not null,
    Name nvarchar(100) not null,
    Value nvarchar(max) not null,
    CreateDate datetime not null
)

INSERT VALUES

MERGE TABLES

DROP TABLE #WidgetSetting

Mas agora o SSMS está reclamando que o objeto já existe na próxima vez que o CREATE TABLEdisparo. O que da?

Acho óbvio que vou ter que declarar a tabela uma vez no início do script, truncar em vez de descartar, mas é frustrante, naturalmente, não poder simplesmente descartar a tabela e usar o mesmo nome novamente.

sql-server sql-server-2008-r2

1 respostas

  1. Best Answer

    Não, o analisador não permitirá que você crie a mesma tabela #temp duas vezes no mesmo lote (e isso não tem nada a ver com o SSMS). Não importa se apenas uma cópia da tabela #temp pode ser criada; por exemplo, na seguinte lógica condicional, que para humanos obviamente só poderia executar uma ramificação, o SQL Server não pode ver isso:

    IF 1 = 1
BEGIN
  CREATE TABLE #x(i INT);
  DROP TABLE #x;
END
ELSE
BEGIN
  CREATE TABLE #x(j INT);
  DROP TABLE #x;
END

    Msg 2714, Nível 16, Estado 1, Linha 8
    Já existe um objeto denominado '#x' no banco de dados.

    E para provar que não é SSMS reclamando em tempo de compilação (um equívoco comum):

    DECLARE @sql NVARCHAR(MAX) = N'IF 1 = 1
BEGIN
  CREATE TABLE #x(i INT);
  DROP TABLE #x;
END
ELSE
BEGIN
  CREATE TABLE #x(j INT);
  DROP TABLE #x;
END';

EXEC sp_executesql @sql;

    Gera exatamente o mesmo erro, mesmo que o SSMS não tente analisar ou validar o SQL dinâmico antes de enviá-lo ao servidor via sp_executesql.

    A correção, é claro, é reutilizar a mesma tabela #temp em vez de descartar, usar uma tabela #temp diferente a cada vez ou não usar tabelas #temp em primeiro lugar.

    Isso não é algo que você deve esperar que o SQL Server trate melhor. Em outras palavras, acostume-se com qualquer solução alternativa que você decidir.

    Veja também esta resposta relacionada no Stack Overflow que fornece uma explicação alternativa:

    • 11

relate perguntas