2008-10-07 4 views
5

A l'origine, j'ai pensé à demander s'il était possible de fournir un champ de dernière mise à jour géré automatiquement avec MS Access.Comment créer un champ "dernière mise à jour" géré automatiquement avec Microsoft Access

Après quelques recherches sur Google, je trouve l'approche suivante:

Private Sub Form_Dirty(Cancel As Integer) 

    Me.Last_Update = Date() 

End Sub 

qui semble faire le travail. Je pensais que je partagerais avec d'autres aussi (et si quelqu'un a quelques bons points qui devraient être considérés, n'hésitez pas à les partager)

Répondre

3

Vous pouvez également mettre ce même code dans une BeforeUpdate. La différence étant que le OnDirty marquera l'enregistrement lorsque vous avez commencé à éditer l'enregistrement pour la première fois; tandis que BeforeUpdate marquera l'enregistrement juste avant qu'il ne soit validé dans la base de données. Ce dernier peut être préférable si vous avez un utilisateur qui commence à éditer un enregistrement, va à une réunion et finit de l'éditer une heure plus tard.

+1

BeforeUpdate est certainement l'événement correct à utiliser, pas OnDirty. –

2

Cela pourrait être votre meilleur choix sur une base de données d'accès avec un fond d'accès - mais Si vous avez un back-end MS-SQL, mettez un déclencheur de mise à jour sur la table afin de pouvoir récupérer les modifications, peu importe d'où elles viennent.

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 
3

De plus, ajoutez une colonne Règle de validation (ou CHECK contrainte) pour assurer la colonne « timestamp » est mis à jour lorsque la table est mise à jour autre que via votre formulaire. La DLL SQL (ANSI-92 syntaxe mode de requête) ressemblerait à quelque chose comme ceci:

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()) 
; 

Une autre approche lors de l'utilisation Jet 4.0 (pré-Access 2007 soit avant la sécurité au niveau de l'utilisateur a été retiré du moteur) est de créer un 'assistant' Jet SQL PROCEDURE (Terme d'accès: Objet de requête stocké défini à l'aide d'une instruction SQL 'Action', distincte d'une requête SQL SELECT) qui met automatiquement à jour la colonne 'timestamp' puis supprime les privilèges 'update' de la table et leur accorde à la place sur le PROC par exemple quelque chose SQL DDL/DCL comme:

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 
; 

L'avantage est ici toutes les mises à jour doivent passer par l'PROC et est donc sous le contrôle du promoteur; l'inconvénient est Access/Jet SQL est que votre formulaire devra également utiliser le PROC, ce qui signifie un changement de paradigme de l'approche standard des «formulaires liés aux données» pour lequel Access est célèbre.

+0

Je suis très confus par cette réponse. Répondez-vous pour un backend Jet ou pour SQL Server? Si Jet, il n'y a pas de déclencheurs ou de procédures stockées et vous devez utiliser des événements de niveau formulaire pour tamponner les enregistrements (cela fonctionne très bien, en fait). –

+1

Ma réponse est pure Access/Jet/ACE et tout le code est ANSI-92 Query Mode Jet 4.0, essayez-le ;-) Jet a en effet la syntaxe PROCEDURE. Mon point est que vous n'avez pas réellement * besoin * d'utiliser un formulaire Access pour obtenir un horodatage dans ACE/Jet. – onedaywhen

+0

Ceci est extrêmement intéressant .... lien vers la documentation à ce sujet? – tbone

Questions connexes