Estou mantendo algum código que tem um gatilho em uma tabela para incrementar uma coluna. Essa coluna é usada por um aplicativo de terceirosA. Vamos dizer que a tabela é chamadateste com duas colunasnum1 enum2. O gatilho é executado em cada inserção denum1 noteste. A seguir está o gatilho:

USE [db1]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER TRIGGER [dbo].[TEST_MYTRIG] ON [dbo].[test]
FOR INSERT AS
begin
SET NOCOUNT ON
DECLARE @PROC_NEWNUM1 VARCHAR (10)
DECLARE @NEWNUM2 numeric(20)

SELECT @PROC_NEWNUM1 = num1 FROM INSERTED
select @NEWNUM2 = MAX(num2) from TEST
if @NEWNUM2 is null
Begin
set  @NEWNUM2  = 0
end
set @NEWNUM2 = @NEWNUM2 + 1
UPDATE TEST SET num2 = @NEWNUM2 WHERE num1 = @PROC_NEWNUM1
SET NOCOUNT OFF
End

Isso funciona bem em inserções simples baseadas em linha, mas há outro aplicativo de terceirosB (suspiro) que às vezes faz várias inserções nesta tabela, algo como isto, mas não exatamente:

INSERT INTO [db1].[dbo].[test]
           ([num1])

   Select db1.dbo.test.num1 from [db1].[dbo].[test]
GO

Isso faz com que o gatilho se comporte erraticamente ...

Agora não tenho acesso à fonte do aplicativoA ouB e controle apenas o banco de dados e o gatilho. Existe algo que possa ser feito com o gatilho para que as atualizações feitas nonum2 estão corretas no caso de várias inserções?

Solução:

A seguir, a solução baseada no código da affan:

 DECLARE @PROC_NEWNUM1 VARCHAR (10)
 DECLARE @NEWNUM2 numeric(20)
 DECLARE my_Cursor CURSOR FAST_FORWARD FOR SELECT num1 FROM INSERTED;

 OPEN my_Cursor 
 FETCH NEXT FROM my_Cursor into @PROC_NEWNUM1

 WHILE @@FETCH_STATUS = 0 
 BEGIN 

 select @NEWNUM2 = MAX(num2) from TEST
 if @NEWNUM2 is null
 Begin
    set  @NEWNUM2  = 0
 End
 set @NEWNUM2 = @NEWNUM2 + 1
 UPDATE TEST SET num2 = @NEWNUM2  WHERE num1 = @PROC_NEWNUM1
 FETCH NEXT FROM my_Cursor into @PROC_NEWNUM1  
 END

CLOSE my_Cursor
DEALLOCATE my_Cursor

Confira aqui uma abordagem baseada em conjunto:SQL Server - Reescreva o gatilho para evitar uma abordagem baseada no cursor