Como gravar data e hora e usuario em todos os registros
Olá amigos, afim de criar um histórico de alterações dos registros do sistema, criei campos com data, hora e usuário que inclui o registro e data, hora e usuário que o altera.
Como poderia criar uma rotina que fizesse isso automaticamente, sem precisar que em cada insert ou update eu tenha que passar parâmetros?
Mario
Como poderia criar uma rotina que fizesse isso automaticamente, sem precisar que em cada insert ou update eu tenha que passar parâmetros?
Mario
Aldus
Curtidas 0
Melhor post
Dbergkamps
11/02/2005
uma forma também pode ser vc tentar assim e criar apenas um campo campo (dados da ultima modificação, por exemplo)
Espero que possa lhe ser útil
Valeu e Boa Noite. :D :D :D
var: UserData: String; Usuario: String; begin //Após o logon no seu sistema, vc grava o nome do usuário que logou. Usuario:=TbUsuarioNome.Value; // Antes de salvar a inclusão/alteração UserData:=Usuario + ´-´ + DatetoStr(Date) + ´-´ + TimetoStr(time); // aí é só atribuir a variável UserData ao campo da tabela.
Espero que possa lhe ser útil
Valeu e Boa Noite. :D :D :D
GOSTEI 1
Mais Respostas
Rodc
10/02/2005
Qual seu banco de dados?
GOSTEI 0
Aldus
10/02/2005
Uso delphi 7 , firebird 1.5 e dbexpress
GOSTEI 0
Aldus
10/02/2005
Uso delphi 7 , firebird 1.5 e dbexpress
GOSTEI 0
Rodc
10/02/2005
CURRENT_DATE e CURRENT_TIME. Tente também CURRENT_USER ou CURRENT_ROLE.
GOSTEI 0
Aldus
10/02/2005
Como assim? não entendi, poderia me explicar melhor?
GOSTEI 0
Aldus
10/02/2005
Olá amigos, não entendi como faço para implementar isso.
O nome dos campos:
DATAINC
HORAINC
USUINC
DATAALT
HORAALT
USUALT
O usuário desses campos será o código do usuário logado ao sistema, dentro do meu cadastro de usuários e não do usuário padrão do Firebird.
Atenciosamente
Mario
O nome dos campos:
DATAINC
HORAINC
USUINC
DATAALT
HORAALT
USUALT
O usuário desses campos será o código do usuário logado ao sistema, dentro do meu cadastro de usuários e não do usuário padrão do Firebird.
Atenciosamente
Mario
GOSTEI 0
Isabelct
10/02/2005
Quanto a data e hora de inclusão/alteração, você pode fazer uma trigger para guardar estas informações. Já para armazenar o nome do usuário, como trata-se de um nome cadastrado em uma tabela sua, acredito que tenha que ser por dentro do Delphi mesmo. Se houver alguma outra forma de fazer, gostaria de conhecê-la também.
GOSTEI 0
Vinicius2k
10/02/2005
Colega,
Esta é uma solução, digamos, criativa :D
1. Crie na sua tabela de usuários uma coluna integer chamada IDSESSAO.
2. No momento do logon do usuário, rode um update set na tabela (dentro da aplicação) dando à IDSESSAO deste usuário o valor da variável do servidor CURRENT_CONNECTION.
3. Crie triggers em Before Insert e Before Update nas tabelas que vc deseja armazenar este histórico. Para o histórico utilize a ID do usuário (em consultas vc poderá relacionar com a tabela de usuários) e sugiro que utilize colunas TIMESTAMP para facilitar a operação ao invés de armazenar data e hora separadamente.
Um exemplo da tabela :
As triggers seriam estas :
4. No momento da desconexão do usuário, rode um update set na tabela de usuários dando à IDSESSAO um valor nulo (dentro da aplicação):
Com isso será armazenado o histórico que deseja...
Não analisei a fundo os contras desta rotina (acabei de inventar isso), mas o devem existir alguns... por exemplo, se a sua aplicação cair, a IDSESSAO do usuário não será setada para nulo e se, por algum motivo, o Servidor cair, a contagem de conexões será reiniciada e um outro usuário ao logar-se pode ter sua IDSESSAO igual a do anterior (o usuario que caiu) até que o anterior se logue novamente... vale a pena vc analisar os riscos, mas trabalho dentro da aplicação vai ser muito pequeno...
Espero ter ajudado...
T+
Esta é uma solução, digamos, criativa :D
1. Crie na sua tabela de usuários uma coluna integer chamada IDSESSAO.
2. No momento do logon do usuário, rode um update set na tabela (dentro da aplicação) dando à IDSESSAO deste usuário o valor da variável do servidor CURRENT_CONNECTION.
update USUARIOS set IDSESSAO = CURRENT_CONNECTION where IDUSUARIO = :idusuario
3. Crie triggers em Before Insert e Before Update nas tabelas que vc deseja armazenar este histórico. Para o histórico utilize a ID do usuário (em consultas vc poderá relacionar com a tabela de usuários) e sugiro que utilize colunas TIMESTAMP para facilitar a operação ao invés de armazenar data e hora separadamente.
Um exemplo da tabela :
CREATE TABLE SUA_TABELA ( ID INTEGER NOT NULL, COLUNA_1 INTEGER, COLUNA_2 VARCHAR(20), COLUNA_3 VARCHAR(10), /* Histórico */ DATA_INCLUSAO TIMESTAMP, USUARIO_INCLUSAO INTEGER, DATA_ALTERACAO TIMESTAMP, USUARIO_ALTERACAO INTEGER );
As triggers seriam estas :
CREATE TRIGGER TRG_USUARIO_INCLUSAO FOR SUA_TABELA ACTIVE BEFORE INSERT POSITION 0 as declare variable IDUSUARIO integer; declare variable IDSESSAO integer; begin select CURRENT_CONNECTION from RDB$DATABASE into :IDSESSAO; select IDUSUARIO from USUARIOS where USUARIOS.IDSESSAO = :IDSESSAO into :IDUSUARIO; new.DATA_INCLUSAO = CURRENT_TIMESTAMP; new.USUARIO_INCLUSAO = IDUSUARIO; end
CREATE TRIGGER TRG_USUARIO_ALTERACAO FOR SUA_TABELA ACTIVE BEFORE UPDATE POSITION 0 as declare variable IDUSUARIO integer; declare variable IDSESSAO integer; begin select CURRENT_CONNECTION from RDB$DATABASE into :IDSESSAO; select IDUSUARIO from USUARIOS where USUARIOS.IDSESSAO = :IDSESSAO into :IDUSUARIO; new.DATA_ALTERACAO = CURRENT_TIMESTAMP; new.USUARIO_ALTERACAO = IDUSUARIO; end
4. No momento da desconexão do usuário, rode um update set na tabela de usuários dando à IDSESSAO um valor nulo (dentro da aplicação):
update USUARIOS set IDSESSAO = NULL where IDUSUARIO = :idusuario
Com isso será armazenado o histórico que deseja...
Não analisei a fundo os contras desta rotina (acabei de inventar isso), mas o devem existir alguns... por exemplo, se a sua aplicação cair, a IDSESSAO do usuário não será setada para nulo e se, por algum motivo, o Servidor cair, a contagem de conexões será reiniciada e um outro usuário ao logar-se pode ter sua IDSESSAO igual a do anterior (o usuario que caiu) até que o anterior se logue novamente... vale a pena vc analisar os riscos, mas trabalho dentro da aplicação vai ser muito pequeno...
Espero ter ajudado...
T+
GOSTEI 1
Aldus
10/02/2005
Obrigado amigos, vou testar suas sugestões.
Mario
Mario
GOSTEI 0