1 Reply Latest reply on Oct 22, 2014 8:00 AM by philmodjunk

    Issue with unstored calc



      Issue with unstored calc


      I have a "Class Manager" database that manages Students enrolled in Classes and tracks their Payments through a join table between Students and Classes called ClassDetail. Here's the way it was set up:

      A field is set in the ClassDetail table when a Student is enrolled in a Class called "ClassID_StudentID", which is the serial ClassID concatenated with serial StudentID. This is basically an "enrollment record". Payment records are created in the context of ClassDetail through a portal from ClassDetail to Payments (creating records through the relationship, where ClassID_StudentID equals ClassID_StudentID). So creating a related payment record sets the ClassID_StudentID field in the Payments table with the appropriate value.


      In the Payments table there is a ClassID field, which is an unstored calc set to display the ClassID from the context of Payments through a relationship from Payments to ClassDetail where ClassID_StudentID equals ClassID_StudentID.

      But this ClassID (unstored calc) field does not update when the ClassID_StudentID field is set from the context of ClassDetail through a portal to Payments. This ClassID (unstored calc) field only seems to validate after the solution is closed and opened again. But the user needs the ClassID field to display on a list view layout based on the Payments table and doesn't want to have to close the solution as a workaround.

      I suppose I could add a text field to Payments and try to simply set it via script trigger with a hard coded ClassID and change layouts to display this test field. But I'm wondering if there isn't some better solution. Is there a way to force the calculation to refresh or validate somehow?

        • 1. Re: Issue with unstored calc

          I don't see the utility to using the concatenated field. Seems needlessly complex. Your join table should have two ID fields, one for the student and one for the class. Each field then serves as a match field to a different table that is part of the many to many relationship.