Bug? Gremlin? Feature?

[comment]

Here's a curious behavior. Try creating new records in the portal by selecting a value for ProductID, OR by selecting a value for Somefield. Watch the unstored calculation cCustomerID populate - or not.

Anyone care to offer an explanation?

CustomerPrices2_copy.fp7.zip

[Ender]

Hmm, same deal in FM8 & 8.5. I don't have an explanation, except that it happens because your unstored calc is used in that Price relationship. A Refresh [ flush ] fixes what's displayed, but doesn't fix the Price Lookup.

[comment]

Thanks for confirming that. What I see is that it happens only when BOTH ProductID and cCustomer are used in that relationship. Take any one of them out, and it populates instantly.

Of course, that's "when", not "because". I still don't understand why an unstored calc should choose not to evaluate just because it is used in a relationship further down the chain. I'd think it's the relationship that depends on the field, not the other way round. Very strange - and very annoying.

[Fenton]

I created another TO instance of Invoice from Items, with another cCustomer field coming from that one. It populated fine. But as soon as I switched the Prices relationship to use that one instead, it not only still did not lookup the price, but it stopped populating; and the original began populating. It's apparently some relational principle here, but it sure seems weird.

[LaRetta]

I ran into the same snag 6 months ago on an identical structure, Michael. Now don't you all laugh ... but what worked in my file was to add a field in LineItems (standard field as Auto-Enter (do not replace) forcing identification of the CustomerID (from the Customers TO) again (auto-enter Customers::CustomerID).

No other auto-enter calculation or boolean would work on my file (whether pulling from Invoices or Customers) except the CustomerID and I had to pull from the Customers TO and not Invoices. So I just ran that theory on your file: I tried creating a number field in LineItems with auto-enter (do not replace, evaluate always) = not IsEmpty( Customers::Customer ) and it won't work. It also wouldn't work when pulling the CustomerID from Invoices. But it worked exactly as my file - when I address specifically the Customers::CustomerID - it works.

My premise is that the 'forced attention' to the Customers::CustomerID, resolves FMs directional confusion. Either of the fields (in your file) now forces the recalculation every time. I'm unsure if this is helpful or whether I'm missing the point entirely but I thought I'd mention it. :

LaRetta

Edited October 26, 2006 by Guest

[LaRetta]

I just looked again at my file ... since I added the CustomerID in LineItems (auto-enter from Customers), I ended up using that field for the connection to my pricing table. The auto-enter prices work and 3 calculations are refreshing (that wouldn't refresh before). So this may not be what you are after but it resolves both issues (prices and calc), I think.

[comment]

I have no problem if I make CustomerID auto-entered. And I suppose it's not too bad since the price is a lookup - so if you picked the wrong customer you have to start from scratch anyway. But I am not looking for a workaround, just trying to understand the logic. I can - after a fashion - understand the many limitations of Filemaker's relational model. They all fall into a pattern. This one eludes me completely. I am leaning towards calling it a bug. Y'all on 8.5 should report it.