ynot8669
asked on
Access Runtime and Data Macros
I want to maintain Creation and Update dates at a record level. I have in the past used the before event but have experienced some issues with this method - that is updated Update date when no change has taken place.
To that end I was thinking of using the Data Macro - before change event to control this. I have tested on a simple Front End form with subform that links to to a backend with the two tables that have the data macro. It works just fine.
However, has anyone successfully tested Data Macros in a Access 2010 Runtime environment and are there any tips or tricks to making it work?
To that end I was thinking of using the Data Macro - before change event to control this. I have tested on a simple Front End form with subform that links to to a backend with the two tables that have the data macro. It works just fine.
However, has anyone successfully tested Data Macros in a Access 2010 Runtime environment and are there any tips or tricks to making it work?
ASKER
That's confusing as I have used them in my desktop test application with the Non-runtime "developer" Access 2010 Version.
See the attached --- albeit basic - manual relink the FE to Database2 which has the Data Macros --- add and change record on either the main form or subform and watch the dates change
DataMacTest.zip
See the attached --- albeit basic - manual relink the FE to Database2 which has the Data Macros --- add and change record on either the main form or subform and watch the dates change
DataMacTest.zip
My bad - that's completely wrong. You can use them with the desktop version.
Have your test results shown this to NOT work correctly? In general, the runtime will do everything the retail version will do with the obvious exceptions (i.e. Design mode, etc).
Have your test results shown this to NOT work correctly? In general, the runtime will do everything the retail version will do with the obvious exceptions (i.e. Design mode, etc).
"AFAIK you can't use Data Macros in a DESKTOP database in 2010"
Yeah, you bad, LOL.
I have tested DMs on recordsets of 1 million records - and they seem to work well. My test scenario was a audit trail situation. This is certainly an area where DMs would excel - considering the code you would have to write otherwise.
mx
Yeah, you bad, LOL.
I have tested DMs on recordsets of 1 million records - and they seem to work well. My test scenario was a audit trail situation. This is certainly an area where DMs would excel - considering the code you would have to write otherwise.
mx
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
To be readressed at a later date
You could very likely modify your current BeforeUpdate code to correctly identify instances where you need to modify the audit trail and where you don't, but we'd have to see the code first.
Allen Browne has an excellent writeup on creating audit trails:
http://allenbrowne.com/AppAudit.html