Início / dba / Perguntas / 8693
Accepted
garik
Asked: 2011-12-03 07:30:57 +0800 CST

Por que TRY CATCH não suprime a exceção no gatilho

  • 772

Tenho uma trigger em uma tabela ( source ) que os dados devem ser copiados para a outra ( target ) em outro banco de dados. Estou tentando implementar o processo de sincronização personalizado para dados: quero que o banco de dados de destino (tabela) esteja atualizado para o banco de dados de origem (tabela). Tenho 3 centenas de tabelas para sincronizar. Alguns deles têm estrutura de dados física diferente. Não posso usar abordagens padrão do Sql Server (replicação, DTS...) devido a diferentes esquemas de dados e outras restrições (tempo de implementação, problemas de ambiente...). Meu objetivo é: esse gatilho NÃO deve impactar em INSERT, DELETE, UPDATE de registros em uma tabela de origem. Eu tentei assim solução:

CREATE TRIGGER dbo.MyTrigger
...
   AFTER INSERT
....
BEGIN TRY
     --RAISERROR('Test error', 16, 2)
END TRY
BEGIN CATCH
  -- nothing
END CATCH

Eu inseri RAISEERRORpara simular erro. Eu esperava, try/catchsuprimido que o erro e o registro foram inseridos (excluídos ou atualizados) com sucesso. Não. Não funciona. Eu tenho erro:

Foi gerado um erro durante a execução do gatilho. O lote foi abortado e a transação do usuário, se houver, foi revertida.

É possível realizar minha solução dessa maneira. Como posso capturar e segurar (suprimir) qualquer erro no meu gatilho?

Que sentido usar try/catchno trigger se não funcionar?

sql-server-2008 trigger

2 respostas

  1. Best Answer

    A transação está condenada a praticamente qualquer exceção e deve ser revertida.

    De "Usando TRY...CATCH no Transact-SQL" no MSDN

    Dentro de uma construção TRY…CATCH, as transações podem entrar em um estado no qual a transação permanece aberta, mas não pode ser confirmada. A transação não pode executar nenhuma ação que gere uma gravação no log de transações, como modificar dados ou tentar reverter para um ponto de salvamento. No entanto, neste estado, os bloqueios adquiridos pela transação são mantidos, e a conexão também é mantida aberta. Os efeitos da transação não são revertidos até que uma instrução ROLLBACK seja emitida ou até que o lote termine e a transação seja revertida automaticamente pelo Mecanismo de Banco de Dados. Se nenhuma mensagem de erro foi enviada quando a transação entrou em um estado não confirmável, quando o lote terminar, uma mensagem de erro será enviada ao aplicativo cliente indicando que uma transação não confirmável foi detectada e revertida.

    Uma transação entra em um estado não confirmável dentro de um bloco TRY quando ocorre um erro que, de outra forma, teria encerrado a transação. Por exemplo, a maioria dos erros de uma instrução DDL (linguagem de definição de dados) (como CREATE TABLE), ou a maioria dos erros que ocorrem quando SET XACT_ABORT é definido como ON, encerra a transação fora de um bloco TRY, mas torna uma transação não confirmável dentro de um bloco TRY .

    Este exemplo mostra o porquê. XACT_STATE() não registra uma transação implícita (por exemplo, nenhum BEGIN TRAN explícito)

    CREATE TABLE TrgTest (gbn int NOT NULL);
GO
CREATE TRIGGER TRG_TrgTEst_I ON TrgTest AFTER INSERT
AS
BEGIN TRY
     SELECT '1', @@TRANCOUNT, XACT_STATE();
     RAISERROR('Test error', 16, 2);
END TRY
BEGIN CATCH
     SELECT '2', @@TRANCOUNT, XACT_STATE();
END CATCH
GO

BEGIN TRANSACTION
INSERT TrgTest VALUES (1)
SELECT 'will not run'
GO
SELECT 'next batch'
GO


BEGIN TRY
    BEGIN TRANSACTION
    SELECT 'a', @@TRANCOUNT, XACT_STATE();
    INSERT TrgTest VALUES (1)
    SELECT 'b', @@TRANCOUNT, XACT_STATE();
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE()
    SELECT 'c', @@TRANCOUNT, XACT_STATE();
END CATCH
GO

DROP TABLE TrgTest;
    • 7

  2. Encontrei uma solução um pouco arriscada* que suprime "transações não confirmáveis" que ocorrem em um gatilho DML.

    Cuidado: geralmente não é seguro suprimir erros de transação em um gatilho, então pense muito antes de tentar fazer isso. Esse método é extremamente inseguro se houver outros gatilhos DML na mesma tabela, porque você pode estar confirmando dados inválidos que outro gatilho pretende reverter.

    Para suprimir erros graves que ocorrem em seu gatilho DML:

    1. Confirme a transação pré-existente implícita que representa o comando INSERT/UPDATE/DELETE inicial
    2. Dentro de um bloco TRY, use sp_executesql para tentar seu negócio arriscado.
    3. No final do seu gatilho, inicie uma nova transação. Isso evitará o erro 3609: a transação terminou no gatilho.
    • 0

relate perguntas