bug? updating stored calc when adding record via portal

[mscholtz]

The setup:

* 2 tables, related via as simple a=b relationship (text fields on both sides) (in my case, the tables are in different files, not sure if that matters)

* in table 2, have the following fields in addition to the relationship key field

- Text1 (text)

- Text1AsNumber (stored calc, = GetAsNumber(Text1))

- at least 1 other field

* have portal to table 2 from a Table 1 layout, set to allow creation of related recs

* include Text1 in the portal, plus one other non-calc field

The Behavior:

do the following:

* go to a new row in the portal, and create a record by entering a value in Text1

* exit the record

* flip over to a Table 2 layout

* did Text1AsNumber evaluate? In my system it doesn't..

* now try again w/ adding from the portal, but this time enter a value in the other field first

* in this case, Text1AsNumber should have been evaluated

The bug seems to involve not evaluating certain stored calcs if the field the calc is based on is the first field updated when creating the record via a portal.

I say certain stored calcs because other calcs do work. For instance, if I make a simple mirror field (i.e. calc field Text1Copy = Text1) this will evaluate. So I can workaround, believe it or not, by setting Text1AsNumber = GetAsNumber(Text1Copy). But a direct calc using GetAsNumber doesn't seem to work the same.

Anyone else seen this? Fixed in 8?

Edited September 12, 2005 by Guest

[Søren Dyhr]

You have to explain why it has to be a stored calc, this is not in my humble opinion not a bug, but rather the way it always have been.

http://www.nightwing.com.au/FileMaker/resources/AutoIndexing.pdf

...look at the date!!!

--sd

[mscholtz]

Sorry, Soren, but once again you have posted a reply that baffles me. I don't know why you sent that link - it doesn't apply to this issue because in my case the field in question is not a related field nor a global - it's a standard text field in the same table, as I explained in my post. (And I'm well aware of the limitations of how one can define stored calcs.)

As to why it has to be a stored calc, you're just going to have to trust me on that one.

Anyone else seen this?

BTW, I have some reason to believe this is a new bug to 7, although I haven't yet gone back to 6 to check.

[comment]

Cannot reproduce your problem. Can you post a demo?

[Søren Dyhr]

As to why it has to be a stored calc, you're just going to have to trust me on that one.

Well if it ain't working as a relational key, what is it then?? ...am I still wondering. Alright it must be you wish to make something to sort rows in the portal. But Comment is right ...according to your description should it work, you must have forgotten to tell us something???

--sd

[mscholtz]

I will try to find the time to do this. I can't post the actual db I'm working on (not even without its data).

But I was hoping that someone would have seen this already, and could give me some insight. (I've already come up with a workaround, so it's not like I need advice in how to get my app working, I was just hoping for some further insight into how FMP works, in all its quirkiness, so I can avoid pitfalls like this in the future.)

Thanks!

[Sanjai]

Did you try keeping the Text1AsNumber field on the portal to see if it calculates any value. I have the similar relationship on version 5.5 and it gives the result if the calculation field is placed on the portal or not.