NUNCA MAIS PASSE RAIVA POR NÃO CONSEGUIR RESOLVER UM PROBLEMA COM O EXCEL - GARANTIDO!

UNIVERSIDADE DO VBA - Domine o VBA no Excel Criando Sistemas Completos - Passo a Passo - CLIQUE AQUI

Você está em: PrincipalArtigosSQL Server 2005 › Capítulo 10 : 15
Quer receber novidades e e-books gratuitos?
« Lição anterior Curso Completo de SQL Server 2005 - Júlio Battisti Δ Página principal Curso Completo de SQL Server 2005 - Júlio Battisti ¤ Capítulos Curso Completo de SQL Server 2005 - Júlio Battisti Próxima lição »
SQL Server 2005 - CURSO COMPLETO
Autor: Júlio Battisti
Lição 170 - Capítulo 10 - O Comando SP_STORED_PROCEDURES

Este comando simplesmente retorna uma listagem dos Stored Procedures existentes no Banco de Dados atual.

Por exemplo, para obter uma listagem de todos os Stored Procedures do Banco de Dados NwindAccess, execute o seguinte comando:

USE Northwind

exec sp_stored_procedures

Com isto, encerramos o nosso estudo básico sobre Stored Procedures. Existem livros inteiros sobre a criação de Stored Procedures e a linguagem T-SQL. No Books OnLine, existe uma referência completa da linguagem T-SQL, a qual é acessada através da opção: SQL Server Language Reference -> Transact-SQL Reference.

Agora vamos ao estudo de triggers.

Desenvolvimento em: Teoria e Desenvolvimento de Triggers no SQL Server 2005

Pré-Requisitos:

  • Fundamentos apresentados na Parte I.
  • Saber utilizar o SQL Server Management Studio e a janela de execução de comandos T-SQL.
  • Noções sobre Integridade de Dados e os tipos de integridade de dados existentes no SQL Server 2005.
  • Noções sobre os comandos básicos da linguagem T-SQL.

Metodologia:

  • Apresentação do conceito de Triggers e dos principais comandos para a criação e utilização de Triggers.

Técnica:

  • Utilização da janela de execução de comandos T-SQL e do SQL Server Management Studio para a criação e execução de Triggers.

Uma trigger é um tipo especial de Stored Procedure, que é executado automaticamente, quando ocorrem operações INSERT, UPDATE ou DELETE, na tabela na qual a trigger foi configurada. Chamamos este executar automaticamente de “disparar a trigger”. Podemos ter triggers associadas com uma ou mais das operações que alteram dados. Por exemplo, podemos ter uma trigger associada com a operação INSERT, porém não termos nenhuma trigger associada com as operações UPDATE e DELETE.

Triggers somente são executadas automaticamente, não podendo ser executadas através da utilização do comando Exec. Uma trigger é sempre associada a uma tabela, porém os comandos que formam a trigger podem acessar dados de outra tabela do mesmo banco de dados. Por exemplo, podemos criar uma trigger para a operação INSERT na tabela Detalhes do Pedido. Sempre que for inserido um novo item de pedido (operação INSERT) será disparada uma trigger que atualiza o nível de estoque do produto que está sendo vendido.

Com o uso de triggers, podemos definir regras mais complexas do que com a utilização de uma Constraint do tipo CHECK. Estas regras mais complexas são conhecidas como “Regras do Negócio”, ou seja, um conjunto de regras que define relações entre os dados do Banco de Dados. Estas relações representam regras do mundo real. Por exemplo, podemos ter uma regra que impeça um gerente de aprovar financiamentos maiores do que um determinado valor. Neste caso, quando o gerente for inserir um novo financiamento no Banco de Dados, podemos criar uma trigger que verifica se o valor do financiamento está dentro do limite definido pela empresa, para este gerente. Caso o valor esteja dentro do limite, o registro é inserido no Banco de Dados, caso contrário, o registro é rejeitado e, uma ação, como por exemplo enviar um e-mail para o chefe imediato, pode ser automaticamente executada pela trigger.

Vamos tornar um pouco mais complexa a nossa Regra de Negócio do exemplo anterior. Vamos supor que o gerente não tenha um limite individual para cada financiamento que aprova, mas sim um limite mensal, isto é, a soma de todos os empréstimos aprovados por um gerente, dentro do mês corrente, não pode ultrapassar um determinado valor. Esta regra aparentemente complexa, também pode ser implementada através de uma trigger. Quando o gerente tenta inserir um novo empréstimo, a trigger faz a totalização dos empréstimos já feitos pelo gerente, durante o mês corrente, já incluindo o valor do empréstimo que esta sendo inserido. Se o somatório estiver abaixo do limite definido pelo gerente, o novo empréstimo é inserido, caso contrário o novo empréstimo será rejeitado e uma ação será tomada pela trigger.

Além de Regras de Negócios, podemos utilizar triggers para modificações em cascata, em tabelas do Banco de Dados. Por exemplo, suponha que você esteja excluindo um cliente da tabela Clientes. Podemos criar uma trigger associada a ação DELETE da tabela Clientes, a qual exclui todos os pedidos (na tabela Pedidos) do cliente que está sendo excluído. Na tabela Pedidos, podemos ter uma trigger associada a ação DELETE, que exclui todos os itens, na tabela Detalhes do Pedido, do pedido que está sendo excluído da tabela Pedidos. Estes itens estão gravados em uma tabela Detalhes do pedido. Além da exclusão, também podemos criar triggers que façam atualização em cascata. Por exemplo, se alterarmos o código de um cliente, na tabela Clientes (ação UPDATE), podemos fazer com que uma trigger altere o código nos pedidos do cliente, na tabela Pedidos.

Uma trigger somente é executada após o comando que a “disparou” ter sido completado. Por exemplo, se tivermos uma trigger associada com uma ação INSERT, a trigger não será disparada enquanto a ação INSERT não tiver sido concluída. Porém, uma trigger é incluída como parte de uma transação, juntamente com o comando que a disparou. No nosso exemplo, o comando INSERT e a trigger estariam no contexto de uma transação. Se o comando INSERT violar alguma regra definida pela trigger, podemos utilizar um roll back na trigger, para cancelar a inserção dos dados feitos pelo comando INSERT. Este mecanismo é ilustrado na Figura 10.8:

Curso Completo de SQL Server 2005 - Júlio Battisti
Figura 10.8 Trigger no contexto de uma transação.

Se o comando, que está sendo executado (INSERT, DELETE ou UPDATE), violar a definição de uma Constraint definida para uma das colunas da tabela, a trigger não irá disparar. Além disso, uma trigger dispara uma única vez para cada comando, mesmo que o comando altere dados em diversos registros. Por exemplo, um comando UPDATE que aumenta em 20% o valor do campo PreçoUnitário de todos os registros. Para este comando, a trigger associada irá disparar uma única vez e não uma vez para cada registro que for alterado.

Podemos ter mais do que uma trigger definida para uma mesma ação – INSERT, UPDATE ou DELETE. Não existe uma ordem definida para a execução de múltiplas triggers associadas com o mesmo comando. A utilização de múltiplas triggers para o mesmo comando não é uma prática muito comum e não é recomendada, pois torna difícil o acompanhamento e o gerenciamento da lógica associada ao banco de dados.

O usuário dono da tabela (dbo) e membros das roles sysadmin, db_owner e db_ddladmin têm permissão para criar e excluir triggers. Estas permissões não podem ser transferidas para outros usuários e roles. Além disso, o usuário dono da trigger deve ter permissão para executar todos os comandos que fazem parte da trigger. Por exemplo, se a trigger precisa excluir dados em uma determinada tabela, o usuário que a cria precisa ter permissão para excluir dados nesta tabela. Se o usuário que criou a trigger não tiver permissão para executar qualquer um dos comandos que a compõem, a trigger irá falhar e um roll back será utilizado para reverter as alterações feitas pela trigger e pelo comando que disparou.

No SQL Server 2005, temos cinco tipos de triggers, conforme o comando com a qual a mesma é associada:

  • DELETE.
  • INSERT.
  • UPDATE.
  • INSTEAD OF.
  • AFTER
  • .NET (novidade no SQL Server 2005).

Uma trigger dos tipos DELETE, INSERT e UPDATE é disparada quando os respectivos comandos são executados. Uma trigger do tipo INSTEAD OF é disparada em substituição a uma das triggers DELETE, INSERT ou UPDATE. Podemos criar triggers INSTEAD OF relacionadas com qualquer um dos comandos – DELETE, INSERT ou UPDATE. Já uma trigger do tipo AFTER é disparada após todos os comandos de uma trigger associada com um DELETE, INSERT ou UPDATE terem sido executados. Se tivermos múltiplas triggers AFTER definidas em uma determinada tabela, para um determinado conjunto de comandos, podemos especificar a ordem de execução das diversas triggers do tipo AFTER.

Uma novidade introduzida com o SQL Server 2000 é que podemos especificar triggers em Views que alteram dados. Já o SQL Server 2005 introduziu as chamadas .NET Triggers. Este tipo de Trigger pode ser tanto do tipo INSTEAD OF quanto do tipo AFTER. A novidade é que um .NET Trigger, ao invés de executar comandos T-SQL, é capaz de chamar código de um módulo .NET, o qual foi instalado no SQL Server 2005. A integração do SQL Server 2006 com o Framework .NET é, sem dúvidas, a principal novidade de programação do SQL Server 2005. Foge ao escopo deste livro, abordar todas as possibilidades de desenvolvimento da integração entre o SQL Server 2005 e o .NET. Existem livros inteiros, só sobre esta integração. Para começar a estudar esta integração, eu sugiro o seguinte livro: “A First Look at SQL Server 2005 for Developers), Editora Addison Wesley, Autores: Bob Beauchemin, Niels Berglund e Dan Sullivan.

Os comandos que compõem uma trigger têm acesso a duas tabelas especiais. Estas tabelas são chamadas de “deleted table” e “inserted table”. Estas tabelas somente existem na memória do servidor, não sendo gravadas em disco. Os registros destas tabelas somente são acessíveis durante a execução da trigger. Para fazer referência a estas tabelas, dentro de uma trigger, utilizamos os nomes deleted e inserted.

A tabela deleted armazena cópias dos registros afetados por um comando DELETE ou UPDATE (armazena o registro antes das alterações). Quando um comando DELETE ou UPDATE é executado, os registros são excluídos da tabela em questão e armazenados na tabela deleted. No caso de registros que estão sendo alterados, na tabela deleted fica uma cópia do registro antes das alterações. Desta forma, a tabela que está sendo alterada e a tabela deleted jamais terão registros coincidentes.

A tabela inserted armazena cópias dos registros afetados por um comando INSERT ou UPDATE. Os registros na tabela inserted são cópias dos novos registros da tabela que disparou a trigger.

Bem, já vimos bastante teoria, agora é o momento de aprendermos a criar e a testar o funcionamento de triggers.

« Lição anterior Curso Completo de SQL Server 2005 - Júlio Battisti Δ Página principal Curso Completo de SQL Server 2005 - Júlio Battisti ¤ Capítulos Curso Completo de SQL Server 2005 - Júlio Battisti Próxima lição »

você conhece a universidade do access?

Universidade do Access - Curso Completo de Access
com tudo para você dominar o Access - do Básico ao
Avançado - até a Criação de Sistemas Profissionais
Completos - Passo a Passo - Tela a Tela

Capa da Universidade do Access

Aplica-se ao Access 2019, 2016, 2013 e 2010!

13 Cursos - 574 Vídeo-Aulas - 63:32 horas

Para todos os detalhes, acesse:

https://juliobattisti.com.br/universidade-do-access.asp

Quer receber novidades e e-books gratuitos?

 
 

Contato: Telefone: (51) 3717-3796 | E-mail: webmaster@juliobattisti.com.br | Whatsapp: (51) 99627-3434

Júlio Battisti Livros e Cursos Ltda | CNPJ: 08.916.484/0001-25 | Rua Vereador Ivo Cláudio Weigel, 537 - Universitário, Santa Cruz do Sul/RS, CEP: 96816-208

Todos os direitos reservados, Júlio Battisti 2001-2025 ®

LIVRO: MACROS E PROGRAMAÇÃO VBA NO EXCEL 2016 - CURSO COMPLETO E PRÁTICO

DOMINE A PROGRAMAÇÃO VBA NO EXCEL - 878 PÁGINAS - CLIQUE AQUI