Unstored Calculations Using The Selector Connector Model

[Ron Cates]

I'm working on a solution currently where I am using a variation of the Selector Connector model https://www.geistinteractive.com/2014/11/21/filemaker-selector-connector-video/. In discussions I have seen there is great emphasis on the idea that the Selector or Connector tables should consist solely of global fields. My understanding is that the concern is regarding record locking. What I was wondering was how the use of any unstored calculations might impact that risk or what other things I should be aware of if I were to include unstored calculations along with global fields in those tables?

[Wim Decorte]

Can you explain a bit more how you think the use of unstored calcs can reduce the likelihood of records being locked?

Using globals means that you are only firing relationships *in your session*, whereas if you use regular fields you may be tripping up other user's sessions.

 

[OlgerDiekstra]

44 minutes ago, Wim Decorte said:

Can you explain a bit more how you think the use of unstored calcs can reduce the likelihood of records being locked?

Using globals means that you are only firing relationships *in your session*, whereas if you use regular fields you may be tripping up other user's sessions.

I use a variant of the Selector Connector concept as well. Your last comment had me thinking. Afaik unstored calcs can't be used for creating relationships as they can't be indexed. It's a nuisance sometimes but understandable and something we just have to live with.

As globals only live on the client, that would imply that creating a relationship using a global means in order for that relationship to be created, the entire table would have to be transferred to the client first? (as in all it's data). Which means it kinda works like a filtered portal? Or does the client submit the global value to the server, and the server creates a temporary client based relationship just for that session/client?

[bruceR]

Quote

 AFAIK unstored calcs can't be used for creating relationships as they can't be indexed.

Sorry, that doesn't add up. Global fields can be indexed?

Other issues aside, globals and unstored calcs can be used on the "left" side of relationships.

[LaRetta]

11 hours ago, Ron Cates said:

What I was wondering was how the use of any unstored calculations might impact that risk or what other things I should be aware of if I were to include unstored calculations along with global fields in those tables?

Hi Ron,

Along with those tables?  You said you were using SELECTOR, right?  SELECTOR must be a single record.  And it must be comprised of only globals so it is session-specific (and so that the child relationships only respond to the session User but it could be global calculations ( which are automatically unstored ) ... if it is based upon global fields within SELECTOR record.  It would not work if the global fields were in other tables because the 'other tables' are the child side and, as explained, globals or unstored calculations can't be on the child side.

If you have a global calculation which is completely dependent upon SELECTOR global fields you will still need to trigger the evaluation at startup.  One way to handle it is to include a trigger field (gTrigger, number) within the global calc and set gTrigger with '1' at session startup (OnFirstWindowOpen).  From then on during that session, if you change the values in any of those globals, the global calculation will update because it references those global fields.

Here, I just found Ray Cologon's explanation I remember from years ago ( he has explained it several times in different venues ):

https://books.google.com/books?id=TDBV3Dg8vnQC&pg=PT535&lpg=PT535&dq=ray+cologon+updating+global+calculation&source=bl&ots=OPOIgsHX2V&sig=NIi_RjI59hsObg1WI35ftAbK5s8&hl=en&sa=X&ved=0ahUKEwjjitbp2ODNAhUDKGMKHfFXCTsQ6AEIKDAB#v=onepage&q=ray cologon updating global calculation&f=false

I hope this adds some depth to your discussion.  :-)

There was an even better example where Comment and Ray discuss triggering a global calculation and they went into some depth on the subject.  I'll see if I can find it.  :-)

Edited July 7, 2016 by LaRetta
Corrected miscommunication ... changed 'unstored' to 'stored'. Globals, by their very nature, are stored.

[Ron Cates]

Thank you all for your responses. I got pulled away and wasn't able to get back to this thread till now. It seems there are a few factors involved that I may not have been aware of, but that aside here is a more detailed explanation of what I'm doing and why I asked about the calc fields.

Using the Selector concept I have a Users table related to a Selector table and from there using global key fields I am establishing filtered relationships to many tables for a variety of purposes.

As an example I have a layout based on the Users table with a portal that looks through the Selector table to display records from my Employees table.
I have a few global filter fields to filter the portal to allow for showing employees based on their status, department and or company assigned to.

Here's where it gets a little funky. I have been experimenting with using a global multikey ID field in the Selector table to establish my relationships instead of basing them directly on the global filter fields.  In this case a field called Seletor::EmpIDs that is populated using ExecuteSQL() to pull in the IDs based on the settings in the global filter fields. The reason for this has to do with having filters that apply across related data. My solution involves multiple companies and each employee can be assigned to one or more companies. So I want to be able to filter the portal to have an option to display employees in the portal based on department which is in the Employees table and company assigned which is in the Companies table, or CompaniesAssigned if the filter is based on a Company ID, but in either case It makes filtering the relationship more complicated and I'm looking for a simpler solution that can be applied throughout my solution for various similar and in many cases more complex situations.

The reason for the question about the unstored calculation is based on things such as creating new records and then having the ID added to the global ID key. I am currently using a trigger field in the Selector table to trigger the global calculation fields but my concern with that is there are a growing number of fields in my Selector table that update based on the global trigger and I'm not sure of the effect of triggering all those calcs when they are not needed. With an unstored calculation field the calculation would only need to update as needed when called. So I was trying to find out if that was a viable option.

I hope that was a clear enough explaination. I find the hardest part of using the forum is conveying an accurate description of what I am doing and what I want to do.

[bcooney]

You can certainly use a global text multi-key in SELECTOR. I have (perhaps irrational) preference to avoid global calcs. So, I'd populate that key with a trigger (OnLayoutLoad?). You could use PSoS to return the ids.

[bruceR]

Note that the global calcs can instead be global fields, defined to populate by an auto-enter calc.

I think this would serve as well for where you wish to use unstored calcs.

And - clear enough? Well; no, I don't think so.

I suspect the pronouncements on unstored calcs in this use case are wrong. It will be an unstored calc based on a global field, and thus still a different value for each user.