Detecting Data Changes

Here's an interesting dilemma. How do you track when specific fields are modified and adjust your JSON object so it only includes the data which was modified? Or, how about knowing when a user has modified specific fields, then having the user interface direct them down a different path than if they had modified others?

In both situations, you simply need to know when a field was modified. Using the Get ( RecordModificationCount ) function we can know THAT a given record was modified and using a modification field we can know WHEN it last happened. What we don't know is when only a specific set of fields is modified. We also may need to know exactly which fields were modified in order to take some type of action. This is where Detecting Data Changes is quite helpful. There are a number of ways this can be accomplished and the solution, as always, depends on what your needs are.

In this video, I showcase a method I use to detect data changes and then generate a JSON object based on specific fields which were changed. If you find your solution needing to work with an external API or needing to simply know when certain fields have been changed then you're sure to find some valuable info within this video and technique file.

AttachmentSize
DetectingDataChanges.zip1.59 MB

Comments

What is the pertinence of all this?
Why not store the content of a field in a variable ''on enter'' and compare it on exit ?
If not the same , save the before and after in some table.
Wouldn't it be the same ?

Jean-Pierre Bergeron
Alpha technologies group inc
402-9999 Boulv de l'Acadie
Montréal, Québec
H4N 3M3, CANADA
jp.bergeron@bergeron.jp
1-514-966-9574

Both approaches will work. What I found interesting from the video was the use of a custom function taking a list of fields to exclude - as Matt points out, CFs are context-independent.

It's the end goal that drives your solution choices. In an audit logging situation the use of hash values doesn't make sense, but here it's a good way of saving storage space as a flag for the changed fields (Matt mentions that some of the fields store MB of data). I happen to think a _better_ process is to use the Get ( ModifiedFields ) and just store a list of relevant field names, but this (a) misses any related fields/records and (b) can't tell you if a field has been changed back to a previous value that happens to match what is already in the external service.

--
Daniel Farnan

Ignorance is curable, not preventable