TRIGGER PARA LOG
Boa Tarde!
Gostaria de Gerar um Log utilizando Trigger do SQL Server.
O usuario Loga-se no sistema,
existe como gerar um log com a trigger pegando este codigo que foi acessado no sistema?
Detalhe, utilizamos um usuario generico para conectar ao sql server.
abrs
Gostaria de Gerar um Log utilizando Trigger do SQL Server.
O usuario Loga-se no sistema,
existe como gerar um log com a trigger pegando este codigo que foi acessado no sistema?
Detalhe, utilizamos um usuario generico para conectar ao sql server.
abrs
Existe. Gatilhos podem ser utilizados para as mais variadas funcionalidades, por exemplo, usamos gatilhos de Log de acesso, Log de operações e ainda para validação de CPF, CNPJ, CEP e Email em várias tabelas.
Mas não existe [Ô]usuário genérico[Ô] no SQL Server. Só para deixar claro aos demais participantes do fórum, o que você está informando é que todos os usuários do aplicativo acessam os dados por meio da conta SQL Server do aplicativo.
Então, existe, sim, como gerar log por usuário, e como disparar o log tanto pelo status da seção quanto por operação, assim como disparar por meio desses gatilhos, mensagens de e-mail de alerta, de cobrança, de convite e de propaganda, sem a necessidade de usar aplicativos. Apenas lembre-se de que no seu modelo atual, o usuário é o mesmo sempre. Deste modo, quem altera dados, quem exclui dados, sempre é o mesmo usuário. Desse modo, o Log gerado não será muito útil.
Em minha opinião pessoal, a aplicação fazer seu acesso por meio de uma conta especÃfica não é errado, aliás é o primeiro passo para que a aplicação funcione á contento, validando os acessos. Mas depois de validar, o acesso aos dados deve ser transferido para a conta SQL Server do próprio usuário. E desse modo, sim, o Log vai surtir mais efeito, além de minimizar bastante a carga das seções, o que vai auxiliar no desempenho dos processos. E o mesmo é válido também para o Oracle. Nos demais engines com os quais trabalhei, não notei nenhuma diferença de desempenho. O Access até piora.
A criação de contas de acesso pode ser feita pela própria aplicação. No SQL Server há dois passos iniciar para criar uma conta de acesso: A criação de um login e a criação do usuário. Login é a conta de acesso ao serviço do SQL Server. O usuário é a vinculação de direitos de acesso de um Login á um catálogo. No Oracle, é bem mais fácil ainda, além de mais flexÃvel, em relação ás regras.
Após esses dois passos, é conveniente a vinculação do usuário á um (ou mais) grupo de regras. Os grupos de regras indicam quem pode ver, manipular e administrar entidades, como tabelas e views. Assim, um grupo pode ser capaz de enxergar sem alterar apenas parte dos dados de uma tabela, enquanto outro grupo pode enxergar e manipular todos os dados, e outro ainda, é habilitado em modificar a própria estrutura dos dados.
CREATE LOGIN, CREATE USER, CREATE SCHEMA, CREATE RULE e CREATE ROLE são tópicos TSQL do SQL Server ibastante nteressantes para a busca, se estiver interessado.
Mas não existe [Ô]usuário genérico[Ô] no SQL Server. Só para deixar claro aos demais participantes do fórum, o que você está informando é que todos os usuários do aplicativo acessam os dados por meio da conta SQL Server do aplicativo.
Então, existe, sim, como gerar log por usuário, e como disparar o log tanto pelo status da seção quanto por operação, assim como disparar por meio desses gatilhos, mensagens de e-mail de alerta, de cobrança, de convite e de propaganda, sem a necessidade de usar aplicativos. Apenas lembre-se de que no seu modelo atual, o usuário é o mesmo sempre. Deste modo, quem altera dados, quem exclui dados, sempre é o mesmo usuário. Desse modo, o Log gerado não será muito útil.
Em minha opinião pessoal, a aplicação fazer seu acesso por meio de uma conta especÃfica não é errado, aliás é o primeiro passo para que a aplicação funcione á contento, validando os acessos. Mas depois de validar, o acesso aos dados deve ser transferido para a conta SQL Server do próprio usuário. E desse modo, sim, o Log vai surtir mais efeito, além de minimizar bastante a carga das seções, o que vai auxiliar no desempenho dos processos. E o mesmo é válido também para o Oracle. Nos demais engines com os quais trabalhei, não notei nenhuma diferença de desempenho. O Access até piora.
A criação de contas de acesso pode ser feita pela própria aplicação. No SQL Server há dois passos iniciar para criar uma conta de acesso: A criação de um login e a criação do usuário. Login é a conta de acesso ao serviço do SQL Server. O usuário é a vinculação de direitos de acesso de um Login á um catálogo. No Oracle, é bem mais fácil ainda, além de mais flexÃvel, em relação ás regras.
Após esses dois passos, é conveniente a vinculação do usuário á um (ou mais) grupo de regras. Os grupos de regras indicam quem pode ver, manipular e administrar entidades, como tabelas e views. Assim, um grupo pode ser capaz de enxergar sem alterar apenas parte dos dados de uma tabela, enquanto outro grupo pode enxergar e manipular todos os dados, e outro ainda, é habilitado em modificar a própria estrutura dos dados.
CREATE LOGIN, CREATE USER, CREATE SCHEMA, CREATE RULE e CREATE ROLE são tópicos TSQL do SQL Server ibastante nteressantes para a busca, se estiver interessado.
Tópico encerrado , respostas não são mais permitidas