All,

I encounter this behaviour on both Mac and Win, in FP7v3.

I have 3 global fields, two of them numeric, one text. The text field points to a related table (this table is in a referenced file); this table returns a numeric key corresponding to the text. An unstored calculation in my local table returns a numeric value from this key and the two numeric globals. The calculation result points to exactly one record in another related table (again, that table is in a referenced file). Fields from this table (one of them a container, but I do not think this is relevant) are shown in the same layout as the globals.

What happens is this: Whenever I change any of the 3 global fields, the calculation result changes accordingly (and correctly). However, the related record is displayed only if I change any of the two numeric fields; when I change the text field, the calculation re-evaluates, giving the correct pointer to the table, but the display does *not* change. If I then change one of the numeric globals (to the same value it had), the correct related record is shown.

I attach the relation diagram (sorry if this seems a stupid, not-too-serious example, but it is an FP7 dexterity training I do for my role-playing friends before I attack anything really serious for my boss). The text WeaponName gets the numeric WeaponKeyNbr that goes into the calculation of pnt_HitResult. pnt_HitResult is correctly calculated and displayed whichever of its source values I change; the correct line from $HITRESULT is *not* shown when I change WeaponName.

(puzzled)

Lutz Pietschker

Is this kind of compound keys needed any more, they were in pre 7 - but if you match the 3 values each their corresponding value on the other side without the calc, but instead a and stacking the relations now allow you to do - wouldn't it do???

--sd

Maybe you are right and this is FP6 thinking on my side- actually I thought about performance (which may not be an issue, I think I will try your proposal). Anyway, the behaviour still puzzles me.

Another problem is that I can't copy the flaw you noticed.. could we see the calc's perhaps - there might be some other matters that causes it ...could be leading zeros - or such???

--sd

Soeren,

I get the same problem if I do away with the calculation and build the db with an FP7 multi-key relationship.

Attached is the test database. Open main.fp7, instructions are on default layout. I could reproduce it on any machine I had access to.

test_fmforum.zip

You will need a Refresh Window [Flush cached join results] script step since your HitResult relationship is based on a calculated field from a different relationship involving WpName_gt. It will work, however, if WpName_gt is not a global.

Thanks for the solution- right, it works perfectly the way you say. Seems I have lots to learn yet...

Hi again

pnt_WpKey_fnn could also be a global lookup field, which removes the need to script anything if it's important that the fields are globals???

--sd

Good call! An auto-enter calculation with 'Do not replace existing value for field' deselected works nicely also.