Tracking changes made to an address block of info in a database

[Josh Davenport]

Assuming the address is usually edited from a form you control, and  
not form random places:

Use one or more TESOs  to do the editing of the fields you wish to  
time stamp.

Attach a procedure to the TESO, and run the procedure as a handler.
Check the "focus" box, so that the procedure is called BEFORE data is  
changed.

In the handler procedure, trap the trigger with
	case info("trigger") beginswith "focus"

Use a fileglobal to store the old data. Since you only need to store  
the data between entering
the text editor and leaving the text editor, if the record isn't too  
big, you could use:
	fgOldData=exportline()

when you exit the text editor

case info("trigger") match "oStreetAddress"

local newData
newData=exportline()
if fgOldData <> newData
	shortcall doTimeStamp
endif

You can simplify the code by using smart naming conventions for your  
objects,
or if this is all that needs to be done here just use "defaultcase"

if your records are large, instead of exportline(), build a custom  
concatenation
	fgOldData=field1+field2+field3
	The advantage of exportline() is that is takes care of all data  
types for you


BTW, I haven't posted for a while, but I have been managing a  
migration from
version 3 to version 5.5 enterprise. Seems to be going well. I will  
post some info on
my strategy soon in case anyone is interested. In particular, I have  
a reasonable method
for updating shared files.

Josh

On Mar 5, 2008, at 11:33 AM, David Thompson wrote:

>> I have a need to track changes made to the address part of the  
>> database so
>> that anyone looking at the record can know when the latest changes  
>> were made
>> to an individual's address. In the original DOS database I had  
>> added a
>> change date field and the  block of data in question had a border  
>> around it
>> with a chgedate field embedded in the frame and relied on user to  
>> remember
>> to update that field. This was less than ideal as we could never  
>> know how
>> diligently end users would be in maintaining the field.
>>
>> I have searched on time stamp and info("fieldname") and  
>> modifyrecord - there
>> is no shortage of material but am I looking in the right area?
>>
>> Question 1 - is treating a block of data this way viable in
>> Panorama -perhaps time stamp coupled with .modifyrecord /info 
>> (fieldnname)
>
> I think it's viable, but it's a little tricky. If you setup a time
> stamp field, it will be updated whenever anything in that record is
> updated, not just the address. .ModifyRecord can be triggered just by
> tabbing through a cell, without making any change at all. You will
> need to provide a way to remember what the address was before it was
> changed, so that you can compare them to see whether a change
> actually took place. You could do that by providing an extra field
> for the complete address. Whenever an apparent entry into an address
> field triggers the procedure, it would assemble a complete address
> from the city province etc. fields, and compare them to the value in
> the complete address field. If they are different, then the complete
> address field and the change date field would both be updated.
>
> You can also setup automatic procedures that are triggered by data
> entry into certain specific fields, (page 316 of the handbook) but
> these can also be triggered just by tabbing through the field, so you
> would still need to have some means of comparing the current value to
> the old value to see if a change has actually occurred.
>
> Dave
> _______________________________________________
> Qna mailing list
> Qna at provue.com
> http://provue.com/mailman/listinfo/qna