Eu troquei o PRINT por RAISERROR nas minhas queries
Desde que comecei com o SQL Server, eu usava PRINT nas minhas queries para acompanhar o progresso da execução no SSMS. Eu incluía um PRINT em pontos importantes, com avisos para me ajudar a identificar o andamento e resultados parciais.
Tudo mudou quando eu descobri o blog do Brent Ozar!
Ok, parece propaganda, mas é verdade...
Quando comecei a estudar o o First Responder Kit, percebi que o Brent Ozar usava RAISERROR ao invés de PRINT. E na verdade isso faz muito sentido, já que o uso de PRINT traz algumas desvantagens:
O PRINT não produz necessariamente nada no momento em que é chamado.
As instruções PRINT não são exibidas no Profiler.
O PRINT não pode receber informações variáveis sem CAST ou CONVERT.
Na minha opinião, o maior problema do PRINT é não exibir seu resultado no momento que o comando é executado. Só isso acaba com o uso do PRINT para exibir mensagens de status.
Vamos ver esse exemplo:
Se rodar esse código no SSMS, você verá as duas mensagens... só depois dos 10 segundos! Assim não ajuda muito a debugar um código, né?
Ok. Se o SQL vai "prender" meu PRINT, vamos usar GO para libertá-lo, certo?
É... mais ou menos, né? Se eu incluir GO, o que vai acontecer com as variáveis que eu utilizo no meu script? Isso, elas serão descartadas. Então voltamos a estaca zero.
Analisando os scripts do Kit, eu aprendi a usar RAISERROR para controlar minhas queries.
Tente este código no SSMS:
Bem melhor, não é? A primeira mensagem aparece assim que iniciamos a execução do script, e a segunda depois de 5 segundos.
O RAISERROR tem vários argumentos, mas só precisamos de 3 para usar como substituto do PRINT em nossos códigos:
Message: a mensagem retornada pelo RAISERROR.
Severity: número entre 0 e 25, que faz o SQL tratar o erro de diferentes maneiras. Eu deixo 0 para não receber mensagens de erro.
State: número entre 0 e 255 que nos ajuda a diferenciar um erro do outro. Eu deixo 1.
E, para encerrar, uma dúvida: alguém sabe onde foi parar o E que falta em RAISERROR???