Existem procedimentos que funcionam bem manualmente , mas não em um trabalho , ou falham quando executados a partir de um aplicativo ou não funcionam na tarefa SQL do SSIS
O meu funciona em todas as sessões menos uma.
este é o código que estou executando - ele chama um procedimento armazenado que obtém as definições de gatilho e as salva em uma tabela temporária.
funciona bem e faz parte do meu trabalho de automação.
IF OBJECT_ID('tempdb.dbo.#Jagannatha_sp_getTriggerDef') IS NOT NULL
DROP TABLE #Jagannatha_sp_getTriggerDef
CREATE TABLE #Jagannatha_sp_getTriggerDef (
DB sysname not null,
parent_name nvarchar(600) not null,
object_id int not null,
trigger_name sysname not null,
is_disabled bit,
i int not null,
[trigger_definition] NVARCHAR(MAX) not null,
primary key clustered (DB,trigger_name,i))
truncate table #Jagannatha_sp_getTriggerDef
exec sp_getTriggerDef @dbname = 'APCore',
@TableName = 'dbo.receivedLog',
@Drop_ONly = 0,
@Radhe = '#Jagannatha_sp_getTriggerDef'
SELECT *
FROM #Jagannatha_sp_getTriggerDef
order by db,i
Eu o executo em uma tabela que não possui gatilhos - apenas para torná-lo o mais simples possível
sai com o aviso
IF 'my_server\_DEVELOPMENT' <> @@ServerName THROW 50001, 'Wrong Server!!!',1
tudo certo.
mas então nesta sessão em particular:
e não há nada de diferente nesta sessão, que eu pudesse identificar até agora.
SELECT *
FROM sys.dm_exec_sessions
where login_name = 'my_company\my_user'
and session_id = @@SPID
o segundo é onde ele falha. todos os outros funciona bem.
o que posso fazer para descobrir o que é diferente? ou melhor ainda, mudar o procedimento para que funcione apesar da diferença?
Encontrei uma saída para este problema. Não consegui descobrir nem tive tempo para entender por que exatamente apenas uma sessão estava tendo esse problema.
Este procedimento meu é embalado com sql dinâmico e usa internamente uma tabela temporária chamada
#Radhe
.Eu estava criando a tabela temporária
#Radhe
dentro do sql dinâmico .Resolvi fazer algo diferente: ao invés de
#Radhe
eu teria uma tabela temporária chamada##Radhe
que é criada fora do sql dinâmico mas usada dentro dele da mesma forma.e isso fez o truque para mim nesta situação.
esta é uma visão parcial do código que está dentro do procedimento armazenado:
este é outro vislumbre do código sql dinâmico:
execução de vários blocos sql dinâmicos e gravação do resultado em uma tabela - se o parâmetro foi fornecido, ou apenas um select.
e este é um exemplo do resultado da execução deste procedimento - um script para descartar todos os gatilhos em um banco de dados (lembre-se que existem dois tipos diferentes de gatilhos ):
ATUALIZAR
Agora eu sei o que aconteceu, pois posso reproduzir o erro. Eu também posso evitá-lo. Eu também mudei minha tabela temporária compartilhada
##Radhe
para uma tabela temporária criada dentro do sql dinâmico, exatamente onde eu precisava. É chamado#Jagannatha_Baladeva
.Meu procedimento armazenado chamado
sp_getTriggerDef
aceita um parâmetro que é um nome de tabela temporária, que uso para retornar os scripts gerados.Quando crio essa tabela temporária e o nome está com o mesmo nome de uma tabela temporária dentro do meu procedimento, ocorrem problemas.
Então porque existe uma tabela chamada
#Jagannatha_Baladeva
INSIDE my stored procedure se fora eu criar uma tabela com o mesmo nome, posso enfrentar situações estranhas.para deixar claro, na tabela externa eu nomeio a primeira coluna
DB5 sysname not null,
mas na tabela DENTRO do meu procedimento a mesma coluna é chamadaDB sysname not null,
assim quando executo o seguinte código:Recebo meu erro original:
Mudei o nome da minha coluna para
DB
e o nome da minha tabela temporária para#some_other_table_name
, mas ainda tive o mesmo erro ATÉ que abri outra sessão no meu SSMS e executei o código novamente:e então funcionou bem:
Eu gostaria de ter mais representante para poder deixar um comentário sobre a resposta do Marcello ...
Mas eu recomendaria contra a tabela temporária global, pois geralmente é um risco de segurança, pois qualquer sessão pode acessar seu conteúdo.
Basta torná-lo uma mesa real que você gerencia sozinho ...