Change Value in Inherit document 1

[Ramlawati]

Dear All ,

I have one database of e-contact contained Company and person form.Some Field in person Form is inherit from Company form.The Problem is , when users change Some value in Company form ie : Phone or addresses , the value that inherite in Person Form is not updated.

Some info:
Company Form ( Fields - Company_name , Company_Phone, Company_email, Company_address)
Person Form ( Person_name,Person_Phone , Company_name(computed field - inherit from Company Form))

My task is to add an agent to update Person document(s) whenever Company document is updated (ie: Change of phone number/address)

Any Help would be apprieciate. TQ

 

[pmonett]

Hello,

I know this problem very well, and any Notes programmer with a few years of experience has certainly gone through it once or twice.
You have a parent document, and a collection of child documents. You need to update the child documents when certain information on the parent document change.
There may be several ways to do this, but there is one sure way. You need a unique identifier for your parent document. The DocumentUniqueID will do nicely. You need to ensure that all child documents have that identifier recorded somewhere. If all your child documents are direct responses to the parent, then it is simple.
Make a hidden view listing parent docs and child docs by the ID. If you have response to response docs, it should not respect hierarchy. Actually, I wouldn't respect the hierarchy in that view anyway, the column sort should handle everything. In that hidden view, sort all documents by your unique identifier. Then show the document type if you wish, and a subject line if needed.
Now, when someone modifies something on a parent or child doc, you can ask if the modification is to be copied to the other documents. If the user answers YES, you can ask if he wishes to update immediately or overnight. If immediate, then trigger an agent manually, else mark the doc as needing overnight treatment and let another agent trigger on schedule.
The scheduled agent needs to collect all docs that need modification, the manual one just works on the current doc. For each document being treated, the agent needs to go to the hidden view, collect all docs listed under the unique identifier being treated, and use the parent to source the update to the child documents.
The additional problem is having a user modify an information without having edit access to some of the documents needing update. With an overnight agent, signed by the server, that issue will disappear.
In any case, you have a certain number of hours of programming before you. If you wish for some development help, I would be happy to oblige.

God luck !

Pascal.

 

[Ramlawati]

im a new one Pascal.. So im not so familiar with agent or scripts..Need your help..

Tq

 

[pmonett]

Well, Ramlawati, I'm back again.

You need help ? You came to the right site. What exactly is it you want to know ?

Pascal.

 

[Ramlawati]

hie pmonett,

Nice to meet u again.

1)I need some example ( coding ) how to update the response Document when the parent document is updated and need some step to do it.
2)Can i do it without using an agent?If yes, what the step i need to do?
3)Do i need to change type of field in the form ( Parent and response)?

TQ

 

[pmonett]

Greetings Ramlawati,

Updating a response doc is a major headache in most cases. Remember that Notes is not a relation db engine, but a document-centric db engine.
That means that the only data dependancies that exist between documents (even main and response docs) are the ones that the developer creates.
So, if you wish to update the response docs if the main doc is modified, there is just about only one way of doing it and that involves writing script.
Of course, you could eventually implement a lookup formula in the fields you wish to have updated, formula that will replace the current value with the reference value every time the response doc is edited.
Unfortunately, this method is severely limited in two respects :
a) the response doc needs to be edited to be updated, and most doc accesses are in consultation, not modification
b) only the edited response doc is updated, meaning someone has to open and edit all response docs for them to be updated, which means being able to access all docs (not always possible)
The conjunction of these two points means that manual updating is undesireable in most cases, and inefficient at best. An agent-based automatic update is the best solution in every case, the only difficulties being the creation of the agent itself and deciding on the frequency of update checks.

What I would do is first decide what fields need to be tracked to ensure proper updating. You are not going to launch an update process if a field on the main doc (say company telephone number) is not used in the response docs.
So make a list of fields who's info is copied into the response docs and create a Query* script (what I call a Query* script is a functionality implementd in more than one Query event of the form) to check if the value changes between open and close of document.
For example, use the Globals section to declare a variable per field to track, use the QueryOpen event to store the initial values of these fields in the global variables you defined, and use the QuerySave event to retrieve end-edition values and detect a change. If a change is detected, set a flag on the document before saving it.
Then, create a hidden, shared view (called UPDATE for example) which lists the UNID of all docs that have the flag activated. In the previous process, if a change is detected in the fields that are being tracked, a flag is set to something (1, or TRUE, or whatever). Saving that document will ensure that it will show up in the hidden view.
Be sure to have a second, hidden view that lists all response docs (only responses !) by the UNID of the main parent document (in the $Response field). Call it "(LkpResponses)", for example. You need to change the properties of this view to ensure that it does NOT display docs with hierarchy - otherwise nothing will ever display in this view since the parent main docs are missing.
Finally, you can create an agent that checks the UPDATE view for all docs it has to work on. For each of these docs, the agent should check the (LkpResponses) view and make a collection of all docs that have the UNID of the main parent doc. If the collection is empty, the agent loops to the next main doc until the end of the view is reached. Remember to reset the flag on the main parent doc (and save it !) before looping.
Don't forget to ensure that the first columns of your tracking views are sorted, whatever way. Otherwise the agent might have some trouble getting the next doc.

As I said, you're going to spend some time on this. I'm ready to help along the way, so don't hesitate.

Pascal.