Unstored Calculations not working when hosted on server

[cocoa123]

Hello and I really appreciate any help you can provide.

I have a FileMaker app that is broken into two files: an interface file and a DB file. The UI file is using the DB file tables as external datasources. The versions are FileMaker Pro 11 files hosted on FileMaker Pro 10 Advanced Server.

I have an ACCOUNT table occurrence that has about 6 "to many" relationship to a TRANSACTION table occurrence. The 6 occurrences form "transaction type" filtered relationships such as travel transactions, training transactions, labor transactions etc. I also have a "to one" relationship with an ACCOUNT_SUMMARY table. The ACCOUNT_SUMMARY table has many unstored calculation fields that work with these transaction occurrences. My layout uses the ACCOUNT table as it's context and shows fields from the account as well as calculated fields from the ACCOUNT_SUMMARY table.

When I run the application locally everything works as expected. If I go into the Account Layout and look at an account the fields are displaying the underlying ACCOUNT_SUMMARY fields fine. However, when I upload the two files: UI and DB to FileMaker 10 Server Advanced and run the application Remotely, then the Account Layout is not showing the calculation fields. The DataViewer debugger shows no value in the ACCOUNT_SUMMARY calculation fields. Strangely, if I create a new ACCOUNT record and then delete it when running my application initializer script then the calculations work fine for all the ACCOUNT records. Is there some explanation for this behavior and is there a more elegant solution to force the calculations to fire when my ACCOUNT LAYOUT loads instead of creating an account record and deleting it in the start up script? It is also weird that I have many other unstored calculations throughout my model and they all work properly; only the ones in that ACCOUNT_SUMMARY table don't initialize.

I appreciate any input you can provide.

thanks

Scott

[Søren Dyhr]

The ACCOUNT_SUMMARY table has many unstored calculation fields that work with these transaction occurrences. My layout uses the ACCOUNT table as it's context and shows fields from the account as well as calculated fields from the ACCOUNT_SUMMARY table.

Only visible fields in your context will force thought unstored fields depending on visible fields residing a relation away, and it's getting even worse with related summary fields, which often will require a script snippet in order to refresh accordingly.

There isn't anything new about this, it's a flaw in your implementation and attempt to see spreadsheet'ish behaviours all over the place, the transaction model is chosen of scaling reasons over recursive structures, and relies fully on scripted actions instead of unstored calc's.

I would suggest you watch the video linked to in this:

http://fmforums.com/forum/showpost.php?post/355270/

--sd

[cocoa123]

Thanks for the link it was very interesting and now it makes sense to me.

thanks again.