Manage Learn to apply best practices and optimize your operations.

A better way to track field changes

If you really to ensure fields have changed, and in an easy way, don't use computed fields to display -- just use LotusScript.

View member feedback to this tip.

If you really to ensure fields have changed, and in an easy way, don't use computed for display fields -- just use LotusScript.

Declare a Public list as variant, then fill the list with keys as the field names you want to have checked for changes. Call a sub on the post open (only when the document is in edit mode); this fills the list with the values for each entry. You can even check if the field exists or not.

Then, in the query close event, run a second sub that compares the values of the list entries with the values you now have on the document, and take appropriate action.

You don't need to add computed fields if the required field checks change. You only add one entry to the list with fields and that's it.

dim aFieldsToCheck list as Variant
Forall field in aFieldsToCheck
 If source.document.hasitem
( listtag( field ) ) then
   aFieldsToCheck =  
source.document.getitemvalue( listtag( field ) )
end if
end forall

Forall field in aFieldsToCheck
 if HasFieldChanged
( source.document, listtag( field ) ) then
   ' do your required action
end if
end forall

function HasFieldChanged( doc as 
NotesDocument, strFieldName as String)
 HasFieldChanged = False 
' per default no change assumed

' this is only one variant of checking
' if you have multi value fields you need 
a more advanced checking mechanism to 
cross check all values (i.e. is the order 
important etc.)
  if doc.GetitemValue( strField )( 0 ) 
<> aFieldsToCheck( strField )( 0 ) then
  HasFieldChanged = true
end if 

end function


The overall idea of this tip is good, but there are some problems.

Suppose a field is not present when the document is loaded, but is present when the document is saved. This can very easily occur if the form design has been modified since the document was last edited, and a field added. This line: if doc.GetitemValue( strField )( 0 ) <> aFieldsToCheck( strField )( 0 ) will then cause an error ("List item does not exist") because strField is not a member of the list.

If the field has a text value when the document is loaded, and has a numeric or date value when the document is saved, the same line will cause an error ("Type mismatch"). This can happen if the form design has been edited since the last time the document was edited, or if the field's input translation formula may return values of different types.

The same line can cause an error if the field contains an "error" value when the document is opened or when it's saved. The error in this case would be "Variant does not contain a container," because an error value is not returned as an array.

As noted in the tip, it doesn't handle multivalue fields. It could easily be modified to do so.

It should also be noted that this tip doesn't work with rich text fields. In addition, it doesn't technically track field changes. It actually just detects field changes as the document is being saved. Tracking would require that the information also be written somewhere for future reference.

Andre Guirard

Do you have comments on this tip? Let us know.

This tip was submitted to the tip exchange by member Michael Zischeck. Please let others know how useful it is via the rating scale below. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.

Dig Deeper on LotusScript



  • Favorite iSeries cheat sheets

    Here you'll find a collection of valuable cheat sheets gathered from across the iSeries/ community. These cheat ...

  • HTML cheat sheet

    This is a really cool cheat sheet if you're looking to learn more about HTML. You'll find just about everything you every wanted ...

  • Carol Woodbury: Security

    Carol Woodbury