Tracking Field Changes
Posted by Theo Heselmans on August 8th, 2007
Some of my customers want to keep track of changes to particular fields. I while back I built a script library, which can be used in any database and form.
Below is a simplified version, to get you started.
Here's what to do in the form:
- Add a field to a form called 'TrackingFields'. Make it multi-value and computed for display, and add the names of the fields to track to it, e.g. "LastName":"Title". You could also fetch this info from a database profile, the database responsible user can update him/herself !
- Put in the form's Global Options: Use "ChangeTracking"
- Put in the PostOpen event: TrackingInit source.Document
- Put in the QuerySave event: TrackingVerify source.Document
Here's the code for the 'ChangeTracking' Script Library:
This is what happens:
As soon as the user opens a document, the values of the 'fields to be tracked' are stored in a global list variable 'TrackingCurrent'
- When the user saves the document, the values are compares with the values initially stored
- If there are changes to those fields, they are stored (in this case in the document itself)
- There's a small 'Assemble' function to handle both single and multi-value fields
Comments and improvements: please !
I've added a more complete code,
with the optional 'TrackingVerifyDB' sub too: ChangeTracking.lss
Category: Domino/Notes | 
Technorati: Show-n-Tell Thursday, SnTT
Comments (3)
There is also a document history class available on OpenNTF:
{ Link }
Check out OpenAudit ({ Link })
Has some of the same features.
Theo, I've been meaning to do my own show and tell Thursday post, but this functionality, including the profile document aspect, is already built into SuperNTF { Link } and relies upon the same history class to which Patrick refers. The way I do it is to employ "Form Configuration" documents that include fields where you can define fieldnames | fieldlabels in a multivalue field, and then drop a single subform on any form which handles everything else, from the tracking itself to displaying the results on the form. It's really VERY easy to deploy and configure.
The one thing that is different with your solution is that the changes are stored separately as opposed to in the current document. I'm double-minded about that, as there are good reasons for doing it either way. Since SuperNTF also uses Chris Blatnick's Application Activity Tracking code (for tracking edits/reads/deletions) from OpenNTF { Link }
I am considering merging the two into one unified, highly configurable whole. I'd love to have your input on that effort.
Great stuff.