I am using an unstored calculation to show how much of a check needs to be posted. The calculation is as follows:

Amount - Sum ( CashReciepts::AmountCredit )

where the amount is in the parent file subtracting the sum of the credits in the related file. Works like a charm performed in the same file where the data is kept. On the contrary, through a file reference, sometimes the calc refreshes and sometimes it just doesn't feel like it (Until the calc field is entered) . I have the layout set to save changes automatically. I don't know if it's a bug or what, but it seems there are some small differences how files act through references and when data and interface are inclusive. (This isn't the first problem I've had to deal with)

or am I just missing something?

I think this is a screen refresh problem. If you are using a script try switching to preview mode and back to browse mode. This is an old trick from older versions of FMP. You can also try the commit script step.

You said, "I have the layout set to save changes automatically." this applies to the layout mode and has no effect in the browse mode.

Correction I misread the above. If you have the box "Save record changes automatically" then that applies to browse mode. However, changes to related data don't change the current record. [color:"red"]

Thank you for the reply Ralph. Unfortunatley, I am trying not to use a scrip. I only would like to show the amount left to post in real time. Good idea with the preview back to browse trick, I have used that one and do like it. Although, in this instance I would like the calc to refresh without having to trigger anything. Sometimes it does work, but not always. Attached is an example of the Interface file not as dynamic as the data file using the exact same data...Change the data in both files and you should see for yourself. It's very frustrating!

TestFile.zip

I downloaded your files. It is working fine for me except if I delete a portal row. If I change data it works everytime and worked when I added a new row.

I updated the file to closer represent how I have it set up in the file I'm having trouble with. The Amount field is set to autoenter however much is left to post that being the SumCalc. If the SumCalc which is unstored does not refresh in time, the autoenter is incorrect. After the amout auto enters, try changing it to a smaller amount as if posting only some but not all of the total amount. Then tab through to see if if refreshes correctly and autoenters the correct amount. BTW thank for bearing with me here.

Eric

Archive.zip

I looked at your new files. I see the problem you are having. I don't have a fix. I did notice that pressing the enter key after entering the amount sometimes causes the SumCal to refresh. This leads me to think that it may be a commitment problem.

I hope to get back to this latter.

Well, I kind of have a workaround... I'm using the XMplStartscript (the free plugin) and I put that in the Autoenter of the Amount field. Then all the scrip does is go to the SumCalc field, causing it to refesh. Seems to work so far. Come to think of it that technique may come in handy for other future problems. Thanks again for the responses.

Eric

I'm also having problems with data not refreshing.

The first problem is with "Unstored Calculated Fields" which display related data. Closing and Opening the database fixes the refreshing, however this, of course, is not a workaround.

The second problem is the refreshing of related data through Portals which have been set with a Script. This is fixable by inserting "Commit" Script Steps where ever changes are made.

Hope a fix for this arrives soon!

Garry

Try Refresh Window ['Flush cached join results'].

For Scripts, I find that the "Refresh Window" is not always reliable, however the strategic placement of the "Commit Record" step fixes the problem.

It is the non-Script unstored Calculations that are real problem

Thank you. All the best.

Garry

Interesting, I've found the opposite to be true. Commit sometimes does nothing whereas Refresh with the 'Flush' step works. I think it has something to do with how 'far' away the calculations are in terms of TO links.

Just to clarify, are you referring to problem 1 or 2 here?

I'm referring to problem 2 "Updating Portal rows with Scripts".

Even with "Commit Records" it is still unreliable. So I'm guessing that both "Refresh Window" and "Commit Records" are not reliable.

This is a converted database FM6 to FM7. With about 70 files. Hence, the relationships are still "external" and "chained".

I'm also working on a new database that has the first problem, however I have to change my thinking to the way I present related data onto a Layout. I am still using "chained" relations rather than taking advantage of presenting data from any Table on the one Layout. I will do some more testing today.

All the best.

Garry

Are you running v3?

I'm getting both problems with v3 on OSX.

However, the Script/Portal problem is on a v2 Server on Windoz.

Garry

Ah, I haven't used Server yet. Have you tried using those same files in single-user? I wonder if the problem is related to committing records on Server.

Yes, the problems seemed to be more obvious on the Server. We did do some limited testing with the FM7 client. Now that more users are "hammering" the Server database these problems are showing up. The Server is being accessed by v3 Remote clients (LAN and VPN) and Terminal Services Clients.

Garry

I have had similar problems.

The solution for changing from browse mode to preview seems to work to refresh a portal. However, when I try to make this into a script using the entre preview mode and enter browser mode it does not work. Any suggestions?

Are you committing the records before entering Preview Mode?

For me, the biggest challenge in using FM 7 is getting my head out of six and into seven. You tend to analyze and attempt to resolve issues from a 'six' perspective. While the refresh of unstored calcs is problematic in seven, don't even go there. Define the calc as stored...

Use the "evaluate" function:

Evaluate("Amount - Sum ( CashReciepts::AmountCredit )";Amount)

Whenever the trigger value, Amount, in your parent file changes the calc will re-evaluate and refresh. If, in addition to "Amount", you need changes in the related file to also update the calc, you can add another trigger field that changes value whenever you add a credit line item to the related file via a scripted event. (The trigger fields for the evaluate function should be stored values in the parent table.)

Evaluate("Amount - Sum ( CashReciepts::AmountCredit )";[Amount;field2])

No preview mode, refresh or flush tricks are needed here...plus you may pick up other benefits in having the calc stored.