Cometendo apenas mudanças específicas feitas dentro de uma transacção que possam ROLLBACK

Question

Esta é uma edição significativa da questão original, tornando-o mais conciso e cobrindo os pontos levantados por respostas existentes ...

É possível ter mulitple alterações feitas em várias tabelas, dentro de uma única transação e rollback apenas algumas das alterações?

No TSQL abaixo, eu não quero nenhuma das alterações feitas por "myLogSP" para voltar sempre ser rolado. Mas todas as alterações feitas pelos vários myBusinessSPs deve reverter, se necessário.

BEGIN TRANSACTION  

    EXEC myLogSP

    EXEC @err = myBusinessSPa
    IF (@err <> 0) BEGIN ROLLBACK TRANSACTION RETURN -1 END

    EXEC myLogSP

    EXEC @err = myBusinessSPb
    IF (@err <> 0) BEGIN ROLLBACK TRANSACTION RETURN -1 END

    EXEC myLogSP

    EXEC @err = myBusinessSPc
    IF (@err <> 0) BEGIN ROLLBACK TRANSACTION RETURN -1 END

    EXEC myLogSP

COMMIT TRANSACTION
RETURN 0

A ordem é importante, os myLogSPs deve acontecer entre e depois das myBusinessSPs (os myLogSPs pegar as alterações feitas pelos myBusinessSPs)

Também é importante que todos os myBusinessSPs acontecer dentro de uma transação para manter a integridade do banco de dados, e permitir que todos os seus alterações para rollback, se necessário.

É como se eu quero que os myLogSPs a comportar-se como se eles não fazem parte da transação. É apenas um fato inconveniente de que eles estejam dentro de um (em virtude da necessidade de ser chamado entre os myBusinessSPs.)

EDIT:

resposta final é "não", a única opção é redesenhar o código. Ou para usar variáveis ??de tabela para o registro (como variáveis ??não se revertidas) ou redesenhar a lógica de negócios para não exigir transações ...

Answer 1

Use SAVEPOINTs , por exemplo.

BEGIN TRANSACTION  

    EXEC myLogSP

    SAVE TRANSACTION savepointA
    EXEC @err = myBusinessSPa
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointA
        COMMIT
        RETURN -1
    END

    EXEC myLogSP

    SAVE TRANSACTION savepointB
    EXEC @err = myBusinessSPb
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointB
        COMMIT
        RETURN -1
    END

    EXEC myLogSP

    SAVE TRANSACTION savepointC
    EXEC @err = myBusinessSPc
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointC
        COMMIT
        RETURN -1
    END

    EXEC myLogSP

COMMIT TRANSACTION

---

Editar

Com base nas informações fornecidas até agora (e minha compreensão dele), parece que você vai ter que re-engenheiro você log SPs, quer para variáveis ??de uso, ou para arquivos de uso, ou para permitir que funcionem 'após a fato' da seguinte forma:

BEGIN TRANSACTION  

    SAVE TRANSACTION savepointA
    EXEC @err = myBusinessSPa
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointA
        EXEC myLogSPA -- the call to myBusinessSPa was attempted/failed
        COMMIT
        RETURN -1
    END

    SAVE TRANSACTION savepointB
    EXEC @err = myBusinessSPb
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointB
        EXEC myLogSPA -- the call to myBusinessSPa originally succeeded
        EXEC myLogSPB -- the call to myBusinessSPb was attempted/failed
        COMMIT
        RETURN -1
    END

    SAVE TRANSACTION savepointC
    EXEC @err = myBusinessSPc
    IF (@err <> 0) BEGIN
        ROLLBACK TRANSACTION savepointC
        EXEC myLogSPA -- the call to myBusinessSPa originally succeeded
        EXEC myLogSPB -- the call to myBusinessSPb originally succeeded
        EXEC myLogSPC -- the call to myBusinessSPc was attempted/failed
        COMMIT
        RETURN -1
    END

    EXEC myLogSPA -- the call to myBusinessSPa succeeded
    EXEC myLogSPB -- the call to myBusinessSPb succeeded
    EXEC myLogSPC -- the call to myBusinessSPc succeeded

COMMIT TRANSACTION

Answer 2

Você precisa pular, basicamente, fora do contexto atual. Há um par de maneiras de fazer isso. One (que eu nunca tentei) é chamar o CLR para fazer a inserção.

Talvez a melhor maneira que está usando o fato de que variáveis ??de tabela não são afetados pela transação. Por exemplo:

CREATE TABLE dbo.Test_Transactions
(
     my_string VARCHAR(20) NOT NULL
)
GO

DECLARE
     @tbl TABLE (my_string VARCHAR(20) NOT NULL)

BEGIN TRANSACTION

INSERT INTO dbo.Test_Transactions (my_string) VALUES ('test point one')

INSERT INTO @tbl (my_string) VALUES ('test point two')

INSERT INTO dbo.Test_Transactions (my_string) VALUES ('test point three')

ROLLBACK TRANSACTION

INSERT INTO dbo.Test_Transactions (my_string) select my_string from @tbl

SELECT * FROM dbo.Test_Transactions
SELECT * FROM @tbl
GO

Answer 3

Temos tido sorte com colocando as entradas de log em variáveis ??de tabela e, em seguida, inserindo as tabelas reais após a confirmação ou anulação.

OK, se você não está no SQL Server 2008, em seguida, tentar este método. É confuso e uma solução alternativa, mas ele deve funcionar. A tabela #temp e a variável de tabela teria que ser configurado com a estrutura do que é devolvido pelo sp.

create table #templog (fie1d1 int, field2 varchar(10))

declare @templog table (fie1d1 int, field2 varchar(10))

BEGIN TRANSACTION      
insert into #templog
Exec my_proc

insert into @templog (fie1d1, field2)
select t.* from #templog t 
left join @templog t2 on t.fie1d1 = t2.fie1d1 where t2.fie1d1 is null

insert into templog
values (1, 'test')

rollback tran
select * from #templog
select * from templog
select * from @templog

Answer 4

Use Savepoints e NÍVEIS transação de isolamento .

Answer 5

não seria o caminho mais fácil ser mover a inserção log fora da transação?

Eu realmente não tenho uma resposta para você para o bloqueio de tabela, eu acho que você já tem a resposta, haverá Have para ser um bloqueio de tabela porque o coluna de identidade pode reverter.

Answer 6

mover a declaração BEGIN TRANSACTION para após a primeira inserção.

Answer 7

Talvez você poderia colocar as inserções / atualizações para as mesas de negócios em seu próprio t1 transação atômica e enrole cada uma dessas operações em outro t2 transação que executa a atualização da tabela de log e t1 (as atualizações da tabela de negócios), sem quaisquer reversões. Por exemplo:

BEGIN TRANSACTION t2
     <insert to log>
     <execute stored procedure p1>
END TRANSACTION t2

CREATE PROCEDURE p1
AS
     BEGIN TRANSACTION t1
         <insert to business tables>
         <rollback t1 on error>
     END TRANSACTION t1

Eu acredito que quando você reverter t1 no procedimento armazenado isso vai deixar a transação chamando t2 inalterados.