I have used mostly separation models and am a little flummoxed with your issue. I too have calculations in relationships and have never experienced this.. Even though we will lack context could you post the calculation for us to see
I'm with datamate on this one. I've never had a refresh issue with relationships in a data-seperation file system except in the GUI file with portal lists. In those cases, a window refresh with flush cache has fixed things, though sometimes a Go To Layout (different layout) followed by Go to Layout (original layout) had to be done to force it. So we do need more details.
I do not know what Peter's scenario is, but I have had a situation which sounds somewhat similar and have been watching this discussion in hopes of finding an answer to my problem.
In my DATA files, I have the tables 1) Checkbook Line Items and 2) Sub Accounts. In the Sub Accts table, I created (10) global date fields which the user can manually specify (5) date ranges to look at the spending activity for all the sub accounts for the specified date ranges. (The user changes these date ranges from the GUI file.) In the Sub Accounts table, I have created (5) calculation fields to sum up the checkbook line amounts for spending in that particular sub acount for the (5) specified ranges. In addition, I created (5) Summary fields to summarize the calculation fields.
The problem I am experiencing is when the user manually changes the date ranges in the globals (from the GUI file), the calculation fields update, but the summary fields do not. In order to get the summary fields to update, I have to open up the underlying DATA file (Manage Database) & close it again. This is the only action that seems to reset the relationships, and thus the summary field amounts. I have tried changing layouts (but only to a layout based on the same table occurence) & refreshing the window to get the Summary field amounts to update, but this does not resolve the problem.
Let me know if you need a more specific example to understand the scenario I sought to describe....
Are you using the global date-ranges to change to actual relationships (in which case you need separate relationships for each range), or are you filtering the portal(s)?
Changing key fields (even globals) should work if you are using the dates at the relationship key field levels and matching them to indexed values in the portal table.
On the other hand, filtering of portals does not change the underlying relationship, so summary fields based on the relationship do not change to reflect portal filters.
The layout I am working from is a listing of the sub accounts, therefore I am not using portals. I have the (5) summary fields within the Header part of the layout.
My date fields are global & I have (5) separate relationships created for each of the calculation fields (using the global date fields at the key field level). I do not know if the date field in the Checkbook Line Items table is indexed, I need to check that!
More things come to mind:
- If you are doing this in Form view, try modifying your layout so that all objects are on the body rather than in the header., and deleted the uneeded header part. (There have been some instances reported where header fields do not play nicely with found sets, though the problems generally appeared when in list view layouts.)
- You indicate the layout uses the subaccounts as the base table. Are the globals in that table or elsewhere? Yuu may be better off using a portal or just using the table in which the globals reside, as I assume that is where the calculations sums reside.
Thanks for your help Stephen. I was just able to look at the solution. The date field was indexed and I was working in table view. The date global fields do reside in the subaccounts table.
I changed my script so that when the date ranges are reset (YTD or 5-year), it switches to another layout based on a different table occurence & then returns back to the original layout. I thought I had tried this previously, but I must not have because it resolved my issue! This seems to go back to your 3/30/12 response/suggestion... I just never considered the importance of switching to a layout based on a different table occurence.