Hi,

I have a portal with related records, each one with a "description" field. I would like the "description" field of the first record to be auto-entered in a field of the partent table ("description_child").

I have tried by using the "Evaluate" function, and the "child::description" field as a trigger, but it doesn't work ...

This is what I have tried (field defined as text, "auto-enter calculation")

Evaluate(

Lookup(Child::description);

Child::description

)

or

Evaluate(

GetField(Child::description);

Child::description

)

I guess that my question is if the "Evaluate" function can use a related child record as a trigger when a field is configured as auto-enter calculated value. If so, I can't make it work! Please have a look at the attached example. Any tips are more than welcome, thanks very much!

autoenter_related.fp7.zip

Edited March 24, 200817 yr by Guest

The easy answer to you question is, no, stored field calculations - using Evaluate() or not - will not update when a field value in a related table changes.

There are more than a few scenarios in which the ability to do so is much desired. Yours does not seem to fit the typical need. What exactly are you trying to achieve here?

Thank you Corn, that's what I thought ... I know it seems strange but what I described is exactly what I'm trying to achieve: having the data of the first related record auto-entered in a parent field so it can be edited afterwards if needed. Thank you for your response!

You can simply place the child field on a layout of a parent - it will show data from the first child (in the sort order of the relationship).

Thank you comment, but I need to be able to edit the field without affecting the data in the child field. What I'll probably do is creating the auto-enter field in the child table and placing it on the layout of a parent.

That is, a "child::description_autoenter" field that is initially populated with the data of "child::description". The problem with this is that if I edit the field and afterwards delete the first portal record then I'll loose the edited data ...

Can you explain the real issue behind this? It seems a very weird requirement, to have a child attribute serve as the initial value for a parent attribute.

One has to ask; why don't you enter the data in the parent record first, then look it up into the child? If you really must have the functionality as you say, then you might want to look at an "event trigger" plug-in, such as the free zippScript.