Clique no banner para conhecer e adquirir o meu treinamento de Bancos de Dados no Azure

SQL Server 2016 SP1 – CREATE OR ALTER em procedures, functions, triggers e views

Visualizações: 1.398 views
Tempo de Leitura: 3 minutos

OlĂ¡ pessoal,
Boa tarde!

Neste post vou demonstrar um novo recurso do Transact-SQL disponĂ­vel a partir do SQL Server 2016 SP1, que Ă© o comando CREATE OR ALTER, que pode ser aplicado em procedures, functions, triggers e views.

Para quem trabalha ou jĂ¡ trabalhou com Oracle, sabe que isso Ă© uma cĂ³pia do CREATE OR REPLACE, existente nesse SGBD hĂ¡ muitos e muitos anos e que desde o meu primeiro contato com o SQL Server (SQL 2005) eu sempre me perguntei porque a Microsoft nĂ£o implementava isso, pois facilitava e muito o dia a dia dos DBA’s e desenvolvedores.

AtĂ© a criaĂ§Ă£o desse recurso, para procedures, functions, triggers e views era possĂ­vel utilizar 3 comandos:
– CREATE
– ALTER
– DROP

Se o objeto em questĂ£o nĂ£o existisse na base e vocĂª executasse o comando de ALTER, o SQL retornava uma mensagem de erro:

Se o objeto em questĂ£o existisse na base e vocĂª executasse o comando CREATE, o SQL tambĂ©m retornava uma mensagem de erro:

EntĂ£o como que o DBA/Desenvolvedor fazia para evitar que essas mensagens de erro ocorressem durante a atualizaĂ§Ă£o de objetos ?

Se existe, apaga e depois cria

Uma forma de se garantir que a execuĂ§Ă£o nĂ£o retorne erro Ă© verificando se o objeto existe na base e caso exista, faz a exclusĂ£o da view/procedure/function/trigger. Nesta soluĂ§Ă£o, eu vejo dois grandes problemas:

  • O cĂ³digo do DROP precisa ser explicitamente declarado com o tipo do objeto (DROP VIEW, DROP FUNCTION, DROP PROCEDURE ou DROP TRIGGER), fazendo com que o nosso cĂ³digo nĂ£o seja tĂ£o genĂ©rico
  • Ao apagar o objeto e recriĂ¡-lo logo em seguida, as permissões desse objeto sĂ£o perdidas e os usuĂ¡rios que tinham acesso a esse objeto nĂ£o terĂ£o mais. Para que isso nĂ£o aconteça, vocĂª terĂ¡ que salvar as permissões de cada objeto antes de apagĂ¡-lo e criĂ¡-lo novamente, o que pode gerar um trabalho muito grande dependendo da quantidade de objetos a serem alterados na base, alĂ©m do risco e da responsabilidade de voltar todas as permissões, de todos os objetos. Para salvar as permissões, vocĂª pode utilizar o script que disponibilizei no post Verificando as permissões de um usuĂ¡rio no SQL Server.

Exemplo de uso:

Se nĂ£o existe, cria e depois altera

Uma outra forma de garantir a criaĂ§Ă£o/alteraĂ§Ă£o de objetos sem erro, Ă© com a soluĂ§Ă£o que vou apresentar abaixo, onde eu verifico se o objeto existe e caso nĂ£o exista, cria um objeto “vazio” e apĂ³s isso, executa o comando ALTER com o cĂ³digo-fonte correto.

Essa soluĂ§Ă£o Ă© melhor que a anterior, pois ela nĂ£o tem o problema da perda de permissĂ£o dos objetos, mas tem o mesmo problema do cĂ³digo nĂ£o ser generalista, pois vocĂª precisarĂ¡ definir o tipo do objeto na instruĂ§Ă£o de criaĂ§Ă£o do objeto “vazio” (CREATE VIEW, CREATE PROCEDURE, etc..)

Exemplo de uso:

CREATE OR ALTER

Recurso disponibilizado a partir do SQL Server 2016 SP1, agora Ă© possĂ­vel utilizar a instruĂ§Ă£o CREATE OR ALTER ao criar Stored Procedures, Functions, Views e Triggers. Ao fazer isso, o prĂ³prio SQL Server irĂ¡ verificar se o objeto existe e irĂ¡ criĂ¡-lo, caso nĂ£o exista com o cĂ³digo-fonte informado ou realizar uma alteraĂ§Ă£o no cĂ³digo, caso o objeto jĂ¡ exista.

Exemplo de uso:

Resultado:
Command(s) completed successfully.

É isso aí, pessoal.
Espero que tenham gostado desse post e atĂ© a prĂ³xima.