Stuart McLachlan
stuart at lexacorp.com.pg
Thu Nov 29 21:17:39 CST 2012
That's the whole point of Access 2010's Table Macros. Any relevant change to the data in the table automagically triggers the defined macro. They have removed the requirement to externally monitor the tables changes. -- Stuart On 29 Nov 2012 at 21:46, William Benson wrote: > RAISING the error is not a problem but something has to trigger it and > knowing when a table is changed is a problem. > > There is nothing I can think of short of a scheduled task that open a > database and run a scan of records (preferably with an iron clad > timestamping policy) to see if something changed since the last check. > > When we knew a system was changing records thru java functions and failing > to update the user and timestamp I wrote routines that mailed me database > snapshots every hour, harvested them from outlook attachments, imported > them into my own standalone access database using a import specification > then ran a record by record field by field check looking for items that > changed without updates to the last modified user id and last modified date. > > When we found this we knew something changed within that hour and we looked > at user logs to see who was online at that time then asked them what they > did. Sometimes we got good info leads and sometimes not.... but we did > eventually track down the problems this way (snapshot & compare). > > > ...grabled by smrat phonn as ususl > On Nov 29, 2012 4:15 PM, "Stuart McLachlan" <stuart at lexacorp.com.pg> wrote: > > > Access 10 - Table macros > > > > Open the table in Design View, > > select Design - Create Design Macro - After Update > > > > You can then select such actions as Raise Error, Log Event, Send Email. > > > > -- > > Stuart