FM - How to Sort both Ways in a Portal?

You make a second global to determine sort direction and a second calc field. The calc fields have exactly the same thing in them except that they have one extra condition. If the Sort global is null (empty) then the first calc field is populated and the second is empty. If the Sort Global has a value in it, then the second calc field is populated and the first is empty.

One you have the two calc fields created, you set one to sort Ascending and one to sort Descending in the Sort order. Depending on the value in the Sort global, one of them will be populated and the other will be null. You can just add a checkbox of Sort global or you can get a little fancier and create a calculated container field that references the Sort global and two additional container fields that hold up arrow and down arrow graphics. Add the calculated container field to the screen and attached a Set Field script step to it that simply switches the Sort Global from null to 1.

I think I get it.  So you have the two calculated fields, let say ascending first and then descending second.  If either one is populated from their respective global fields, the other is null and so a null sort, even if it is first, makes them all equal in sort order so only the second calc field will have any effect.  Correct?

Exactly

Solution works; however, I've timed my selections and there is a full 5 second delay after choose the sort option.  The portal is choosing from a 31,000 rec table, but most of those are already filtered out due to the first join being Prop Code to Prop Code and the second join limiting it to just the past 183 days at the most.  So, the average number of recs before filtering is only 50.  Any ideas?  See attached for sort field calc as well as the Table Join.
-Sortscreenshot.jpg

P.S. - I put a 1 instead of "", but that didn't speed it up.  Also, one improvement I made is to create a default sort.  I did this by having the second calc field in the sort (the Descending field) when it is empty to sort be my default of Rec ID.  Thus, if both fields are empty, the first will sort by 1 and then the second by Descending Rec ID.  If only the Descending is empty, it won't effect the sort to be RecID because the first ascending sort takes precedence.

Well, one thing that I know affects speed is the order and type of predicates in the relationship. Someone did some testing a while back and found that using  >  <  ≤  ≥  very significantly slows interactions with the related records, so having those first may be hurting your performance. I would suggest re-ordering your predicates so that 1) the  =  predicates come first, and 2) of those  =  predicates, put the  most restricting first, meaning the ones that narrow the scope of records being related to.

Still testing.  Move the < and > statements lower in the TO link and still have 4-5 second delay.

Hmmm.... well this might be an instance where having two portals on an invisible tab object works better...

Tried the two portal option, but it didn't significantly reduce the processing time of 4-5 seconds.

Perhaps I didn't mention this but the two portal solution requires that each portal have a separate TO, one set to sort one direction at the relationships level and one set to sort the other direction at the TO level.

Does the two-portal solution also mean that you need separate global fields for each, otherwise it seems that a change in one fires of the calculation for the other.

Yes, once I took the calculated sort out of the portal's sort filter, processing time went from 4 seconds to under 2.  This may be in part due to the fact that I have 10 filters already on the portal.  For sorting, I'll use the multiple, fixed presorted portals as you stated.  Thanks for hanging in there on this one.