This is a really deep and complex topic, so I thought I would add some color here. Quick Base is an in-memory database that computes very complex calculations extremely quickly. For some more details on this,
here is a helpful use case I wrote some detail on.
As you can imagine, summary fields get enormously complex. This is especially true when tables have millions of records and then that summary is driving other lookups, formulas, or more summary fields. To keep Quick Base performant and ensure data accuracy, there are always tradeoffs that have to be considered.
In the case of summary fields, Quick Base leverages extensive logic to build the summary fields dynamically so that the calculations are very fast. The nature of a dynamic field though means that it can change based on anything - i.e., the time of day down to a millisecond. Because of this, there is the chance that data as part of a relationship where a calculated field is the key,
might not be accurate, and therefore we impose a protection at this point to ensure the accuracy of data.
The workaround Mark suggested is solid and would work because the actual key is a true data field QB can rely on behind-the-scenes. Of course, you have to know to capture the changes at the right spots in the application.
All that being said, I do have a work item in my backlog to evaluate how we can do some of this for you on the backend and open up more use cases here. It isn't prioritized yet but it is something I am interested in diving into. Feel free to post your use cases here so I can learn about all of them and see if we can factor them into future releases.
