YA script bug in FM8

[Ender]

Here's another bug that appears to only happen in FM8. If looping through portal records, aggregate functions like Count() fail to evaluate if the record is open (like when the cursor is in a field on the portal.)

See the attached sample.

The problem can be avoided by adding a Commit Record[] step prior to the step count() is used in. :

CountTest.fp7.zip

[Søren Dyhr]

Hi Mike

We, were there in this thread:

http://www.fmforums.com/forum/showtopic.php?tid/171459/post/182944/hl/ownership+dyhr/#182944

It seems you're supporting my understanding of the problem???

--sd

[Ender]

An, an interesting phenomenon: If there's a grandchild table related off the child table, and you're in a child portal on a layout of the parent, then the Sum() or Count() on a grandchild::field will show the Sum() or Count() of that portal row's child records. Although I don't recall hearing anything about this as a feature of FM8, this may be the intended behavior, which is why it would fail for counting the child records.

[Søren Dyhr]

Hi Mike

In the other thread were both Michael and I puzzeled by the need for such a control structure, could you enlighten us ...since you have almost the same scenario??

The next question is then; It's the ownership of the record that matters isn't it???

--sd

[Ender]

Well, that 'interesting phenomenon' structure was just to test the focus (or context), which is what seems to have changed in FM8. This ability to put subtotals in the child table while in a portal in the parent table is new.

The sample in my original post illustrates my problem using the count() for loop control, where the loop is used to run checks on the data in the line items. Since the process sets other fields in more than one table, I couldn't just use Go to Portal Row [ Next; Exit after Last ] to leave the loop when done. Although rivet's problem was a little different, your observations were correct about the focus--except that this change in focus is present in FM8, not in FM7.