Cómo crear un campo de "última actualización" administrado automáticamente con Microsoft Access

Question

Originalmente pensé en preguntar si habría una manera fácil de proporcionar un campo de última actualización administrado automáticamente con MS Access.

Después de algunas google me encontré siguiente enfoque:

Private Sub Form_Dirty(Cancel As Integer) 

    Me.Last_Update = Date() 

End Sub 

que parece hacer el trabajo. Pensé en compartirlo con otros también (y si alguien tiene algunos puntos buenos que se deben considerar, siéntase libre de compartirlos)

Answer 1

También podría poner el mismo código en BeforeUpdate.

La diferencia es que OnDirty etiquetará el registro la primera vez que comenzó a editar el registro; mientras que BeforeUpdate etiquetará el registro justo antes de comprometerlo con la base de datos.

Esto último puede ser preferible si tiene un usuario que comienza a editar un registro, va a una reunión y luego termina de editarlo una hora más tarde.

Answer 2

Esa podría ser su mejor opción en una base de datos de acceso con acceso posterior, pero si tiene un back-end de MS-SQL, coloque un activador de actualización en la tabla para que pueda ver las ediciones, independientemente de dónde provengan.

CREATE TRIGGER [Table_stampUpdates] ON [dbo].[Table] 
FOR Update 
AS 
BEGIN 
UPDATE Table 
SET 
modified_by = right(system_user, len(system_user) - charindex('\', system_user)), modified_on = getdate() 
FROM Table inner join inserted on Table.PrimaryKey = Inserted.PrimaryKey 
END 

Answer 3

Además, añadir una regla de validación de la columna (o CHECK restricción) para asegurar la columna 'marca de tiempo' se actualiza cuando la mesa está siendo actualizada que no sea a través de su formulario. La DLL de SQL (ANSI-92 sintaxis modo de consulta) sería algo como esto:

CREATE TABLE MyTable 
(
    key_col INTEGER NOT NULL UNIQUE, 
    data_col INTEGER NOT NULL 
) 
; 
ALTER TABLE MyTable ADD 
    my_timestamp_col DATETIME 
     DEFAULT NOW() 
    NOT NULL 
; 
ALTER TABLE MyTable ADD 
    CONSTRAINT my_timestamp_col__must_be_current_timestamp 
     CHECK (my_timestamp_col = NOW()) 
; 

Otro enfoque al utilizar Jet 4.0 (pre-Access 2007, es decir antes de la seguridad a nivel de usuario fue eliminado del motor) es la creación de una 'helper' Jet SQL PROCEDURE (Término de acceso: objeto Query almacenado definido mediante una instrucción SQL 'Action', distinta de una consulta SQL SELECT) que actualiza automáticamente la columna 'timestamp' y elimina los privilegios 'update' de la tabla y los otorga en cambio, en el PROC, por ejemplo SQL DDL/DCL algo como:

CREATE PROCEDURE MyProc 
(
    arg_key INTEGER, 
    arg_new_data INTEGER 
) 
AS 
UPDATE MyTable 
    SET data_col = arg_new_data, 
     my_timestamp_col = NOW() 
WHERE key_col = arg_key 
; 
REVOKE UPDATE ON MyTable FROM PUBLIC 
; 
GRANT UPDATE ON MyProc TO PUBLIC 
; 

La ventaja aquí es todas las actualizaciones deben pasar a través de la PROC y por lo tanto está bajo el control del desarrollador; la desventaja es que Access/Jet SQL es que su formulario también tendrá que usar el PROC, lo que significa un cambio de paradigma lejos del enfoque estándar de 'formularios enlazados a datos' para el cual Access es famoso.