É bem conhecido que o SSMS (ou talvez o SQL Server, mas acho que mais o SSMS) atrasa as PRINTmensagens até que várias linhas (40) sejam reunidas no buffer, antes de serem realmente impressas na janela de mensagens no SSMS (exceção : algo mais é impresso, por exemplo, o número de linhas afetadas por um UPDATE ou o lote está pronto).
Então eu costumo usar RAISEERROR(<text>, 0, 0) WITH NOWAITpara imprimir imediatamente. Isso funciona bem para as primeiras 500 linhas, depois disso o SSMS parece começar a buffer novamente (50 linhas, começando em 1000 linhas, o buffer parece aumentar para 1000).
Alguém sabe como posso evitar esse "recurso de buffer" (por exemplo, se eu executar manualmente as atualizações estatísticas usando a solução de manutenção Ola Hallengreens, prefiro saber o que ele realmente faz no momento sem precisar usar sp_whoisactive etc. ).
PS: Você pode simular esse comportamento usando o seguinte "script"
DECLARE @i INT = 0
WHILE @i < 10000
BEGIN
SET @i += 1
RAISERROR('Step %i', 0, 0, @i) WITH NOWAIT
--PRINT @i
WAITFOR DELAY '00:00:01.0' -- wait 1 second, feel free to decrease
END
Para ter controle total sobre a exibição da mensagem, você pode executar o script com o PowerShell usando System.Data.SqlClient, manipulando o evento InfoMessage e definindo FireInfoMessageEventOnUserErrors na conexão. Não acho que haja uma maneira de controlar o comportamento no SSMS ou em outras ferramentas do SQL Server. – Dan Guzman ontem