Diversas Transações

[Oysk]

Oi, galera!

Estou com a seguinte situação:

1. Inicio uma transação através da aplicação

2. Essa aplicação chama uma procedure

3. Ocorre um erro durante a execução da procedure (forço uma exceção)

4. Salvo as informações relativas ao erro numa tabela própria, utilizando outra transação

5. Retorno para a aplicação

6. Dou ROLLBACK a partir da aplicação

O problema é que, quando executo ROLLBACK, as operações salvas na tabela própria são desfeitas... ou seja, o meu COMMIT na outra transação não é considerado...

Segue exemplo do que estou tentando fazer...

DECLARE @P_DT_PGTO datetime
DECLARE @P_COD_USUARIO int

SET @P_DT_PGTO = '20100515'
SET @P_COD_USUARIO = 152

BEGIN TRANSACTION TRAN_01

BEGIN TRY

    EXECUTE [SIP].[SP_GERA_SIP_PGTO] @P_DT_PGTO, @P_COD_USUARIO

    COMMIT TRANSACTION TRAN_01

END TRY
BEGIN CATCH

    ROLLBACK TRANSACTION TRAN_01

END CATCH



CREATE PROCEDURE [SIP].[SP_GERA_SIP_PGTO](
    @P_DT_PGTO DATETIME,
    @P_COD_USUARIO INT
)
AS

BEGIN

    -- VALIDA PARÂMETROS
    IF (@P_DT_PGTO IS NULL) OR (@P_COD_USUARIO IS NULL)
    BEGIN
        BEGIN TRANSACTION TRAN_02
        
        INSERT INTO SIP.LOG_SIP('DATA DE PAGAMENTO OU USUÁRIO NÃO INFORMADO(S)) 
        
        COMMIT TRANSACTION TRAN_02
        
        RAISERROR('DATA DE PAGAMENTO OU USUÁRIO NÃO INFORMADO(S).', 16, 1)
    END

END

É possível fazer o que estou querendo?

[]'s

[fulvio]

Bom dia Oysk,

Tem como fazer sim, desde que o tratamento do erro seja administrado pelo sql.

você inicia a transação via aplicativo e depois chama uma procedure. porque não chamar a procedure e iniciar a transação dentro dela mesmo? O Try/Cath estão corretos.

O controle das transações cabem ao Banco, e não ao aplicativo. Pense comigo: se o aplicativo abre uma transação, e no meio da execução da procedure o PC é desligado.... quem fechará a transação? A probabilidade de ocorrer isto é baixa, mas existe.

Na procedure, você abre uma transação (TRAN_02) apenas para fazer um insert. A transação é utilizada quando se deseja fazer mais de uma manipulação em uma única transação.

Se você fizer dois inserts desta forma:

insert into ....

insert into ....

Está implicito nos comandos, depois de cada insert, um commit. Sendo assim, o sql faz um a um e "commita" um a um.

Se você fizer dois inserts assim:

BEGIN TRANSACTION

insert into ....

insert into ....

COMMIT TRANSACTION

O sql irá efetivar (gravar) os dois insert´s em uma única transação.

Voltando ao seu exemplo... por ser apenas um insert, faria desta forma:

DECLARE @P_DT_PGTO datetime
DECLARE @P_COD_USUARIO int

SET @P_DT_PGTO = '20100515'
SET @P_COD_USUARIO = 152

EXECUTE [SIP].[SP_GERA_SIP_PGTO] @P_DT_PGTO, @P_COD_USUARIO

CREATE PROCEDURE [SIP].[SP_GERA_SIP_PGTO](
    @P_DT_PGTO DATETIME,
    @P_COD_USUARIO INT
)
AS
IF (@P_DT_PGTO IS NULL) OR (@P_COD_USUARIO IS NULL)
BEGIN
    INSERT INTO SIP.LOG_SIP values('DATA DE PAGAMENTO OU USUÁRIO NÃO INFORMADO(S)')       
    IF @@ERROR>0 
    BEGIN
        -- Aqui você coloca o seu tratamento de erro. Inserção na tabela de erro, etc.
        RETURN
    END
END

Mas se você tiver uma estrutura maior, com várias manipulações, você pode implementar na procedure como fez o Try/Cath. Só lembrando que você dá o ROLLBACK e depois grava as informações:

BEGIN CATCH
    ROLLBACK TRANSACTION
    -- Aqui você coloca o seu tratamento de erro. Inserção na tabela de erro, etc.
END CATCH