portal not updating

[synergy46]

 

i am using fm18 adv ....single user app.

i have 2 tables:  stock & stock_transactions.

I have a layout based on stock with a portal based on--[ stock_transactions  it works great.   But in the sock_transaction table I have a calculated field: c_stlt-->

IF (TRANS_DATE+365>=GET (CURRENTDATE);"LONG";"SHORT").  I can see in the data viewer that when I select the 2nd row in the portal and type in a date, fm shows the date from the top row ,  I need to get _c_stlt to work off the date in it's same row.   What am I missing?? 

[AHunter3]

In the field definition for a calculation field, there is a button marked "storage options"

Click it.  You should see a checkbox for this option:

"Do not store calculation results -- recalculate when needed"

 

It needs to be checked.

 

Why:  A "Get" function -- such as Get(CurrentDate) -- is not re-evaluated whenever it changes.  Because FileMaker doesn't notice.  So a stored calculation result will store the outcome of Get(CurrentDate) when the record (or field) is first created, and then when the day rolls over it is out of date, it's wrong now.

 

An unstored calc field will come up with a (correct) value on-the-fly when asked to display it -- when "needed".

 

[synergy46]

Idid that.  It is not updating correctly.    As an aside  i am currently trapprd in a recursive script.  Is there a way to break out?  thanks for the thoughts

[AHunter3]

If your script does not have user abort turned off, hitting the Escape key (Windows) or Command-period (MacOS) will abort a running script.

 

If it does have user abort turned off, that won't work, in which case:

Go to "Tools" and invoke the script debugger.  It will bring any currently running script to a pause, and it has controls that let you kill the script.

 

Although I assume that since you posted this yesterday, you haven't been sitting at your computer watching a recursive script running in perpetuity.  But for next time...   

 

Now about your field not updating correctly... can you upload a copy of your file?  The change I recommended should work unless something else is amiss.

[AHunter3]

Mockup of your db, based on your screen shot.  Field defined as discussed.

Appearance prior to Sept 28 (was originally posted on Saturday Sept 26):

On Sept 26, I wrote:  Sept 7, 2019 is indeed "SHORT" and Sept 16 is indeed "LONG".  Picking dates closer to exactly one year ago, Sept 25, 2019 is just over a year ago and is "SHORT"; Sept 28, 2019 is just a hair less than a year ago and evaluates as "LONG".

 

Edited Sept 28 to post new screen shot, showing that the value does roll over as it should:

 

Are you saying that, in your copy, the Sept 28, 2019 record would continue to say "LONG" even after the end of September 2020?