Passar parametro pra trigger

[kauebranco 0]

Pessoal , To tentando criar um sistema de geração de Log automático .. tudo com TRIGGER .. só que veio a seguinte dúvida .. como saberei o ID do usuário que fez o INSERT NA TABELA ??USER_NAME não me serve .. pois ele pega o USER que se logou no SQL .. e não é isso que me interessa .. é o ID na tabela de USUARIO que me interessa mesmo ..e na hora de salvar o Log .. como vou saber qual o usuário que executou ??Se tivesse uma maneria de passar de uma procedure pra uma trigger um valor ... ou de uma trigger pra uma procedure ..mais ainda teria que ser uma variável do tipo Session .. como no ASP .por exemplo.. pq várias pessoas estarão usando ao mesmo tempo ..

[MisterPe 0]

kauebranco,Não existe possibilidade de passar parâmetros externos para uma trigger !Então você vai ter de resolver o problema de identificação do usuário pelo próprio banco, para implementar seus logs.Existem dois modos de fazer isto...O mais fácil (que pelo jeito não serve pra você) é utilizar usuários diferentes para conexão da aplicação no banco. Baseado em um modelo misto de autenticação, você poderia, descobrir o usuário que autenticou via sistema operacional e relacionar este logon no SO a sua tabela de usuários. Este esquema não serve para você por dois motivos :1) Sua aplicação é web2) Imagino que você só tenha um usuário único para conexão via aplicaçãoO mais difícil (que acredito ser o único modo de você resolver este problema) é baseado em uma idéia simples : identificar o número do processo daquela conexão ("spid") naquela sessão do usuário e armazená-lo na tabela de usuários. O processo não é tão trivial, mais em linha gerais você vai precisar...1) Criar uma nova coluna na tabela de usuário (spid int null)2) Na rotina que trata o login do usário (na aplicação) recuperar o spid da conexão que acabou de ser feita (utilize a propriedade @@SPID do sql server)3) Fazer um update na tabela de usuários armazenando este spid para o usuário que acabou de logar (amarrando logon = spid)4) Suportar as operações normais que sua aplicação vai desempenhar (ou seja, deixar o usuário usar o sistema)5) Na trigger que você vai querer "monitorar" o usuário, inserir um tratamento descobrindo qual o "spid" que solicitou tal alteração > > Repare que trata-se de um processo baseado no próprio banco, pois o sql server armazena cada processo de conexão contra um spid único > Para descobrir que o spid : utilize novamente a propriedade @@SPID do sql server > Fazer um select na tabela de usuário descobrindo o usuário que logou neste spid (passo 3) > Atualizar o log baseado no relacionamento da sua tabela de usuários vs o @@SPID que fez a alteração6) No logoff da aplicação, "limpar" a coluna daquele usuário que esta desconectando.(viu... eu falei que não era muito trivial !)A questão mais importante desta abordagem (que é justamente aquilo que vai garantir que ela vai funcionar) é... garantir vai haver uma única conexão ao banco de dados durante uma sessão da aplicação !!!Se isto não acontecer, ou seja, no seu programa existirem outros pontos de conexão ao banco de dados... esqueça este negócio não vai funcionar !!!Se quiser ir por este caminho, recomendo uma pesquisa no books on-line em :1) @@SPID2) SUSER_SNAME()Espero que caso não seja exatamente isto que você precisa, apareçam outras pessoas aqui pra te ajudar. Coloquei apenas uma idéia, considerando o que entendi do teu problema...T+

[kauebranco 0]

você entendeu perfeitamente o que eu quero ...mais realmente ... como você mesmo disse .. naum é uma coisa muito simples .. e sim .. minha aplicação terá vários pontos de conexão ...se eu garantir que utlizarei a mesma conexão num processo de INSERT ... e antes de executar esse INSERT eu criar uma tabela temporária com o ID do usuário gravado la ... eu conseguiria pegar esse ID dentro da TRIGGER né ?? e pelo fato de terem vários usuários conectados ao mesmo tempo ... o SQL server se perderia ?? ou trabalharia certo ?? pois cada conexão criará a sua tabela temporária .. naum teria perigo de pegar o ID errado ???

[MisterPe 0]

O processo de conexão é único (ou deveria ser) e não tem nada a ver com inserts, updates ou deletes (seja em tabelas temporárias ou definitivas). Chamei de "conexão" o ato de você passar os parâmetros de autenticação e "logar" no banco. Normalmente, isto ocorre uma única vez, no início da sessão do sistema para um determinado usuário !Dependendo da arquitetura e do tipo de linguagem, você pode ter outras conexões sendo executadas depois que o sistema foi carregado.Um exemplo clássico é o caso do uso de objetos "ttable" no Delphi. Toda vez que você declara um objeto deste tipo para manipular determinada tabela no sql server, o delphi cria uma nova conexão no banco que somente será derrubada quando o programa que criou o objeto for finalizado (regra geral). Então você, para uma mesma sessão do sistema, vai ter diversas conexões (desnecessárias) ao banco... por uma questão que não é do sql server mais um problema da linguagem.Todas as tabelas temporárias criadas diretamente pelo sql server são criadas dentro da mesma sessão de conexão original, portanto imagino que você não terá problemas neste momento. O quê não significa (necessariamente) que você não terá problemas em outros (hehehehehe...).Recomendo o seguinte...Crie algumas tabelas de triggeres de teste e tente simular está arquitetura que te passei. Acho que dá pra você trabalhar deste jeito. Eu tenho mais de um sistema (Delphi & PHP) funcionando deste modo e tudo vai bem... aliás, muito bem !