Quickest portal filtering set up

[eoneon123]

I know this is a terribly broad question, but I was wondering what types of factors slow portal filtering aside from sheer volume of records. Is it generally quicker to filter by relationships rather than the portal itself? Does filtering a relationship by way of a calc field slow the process? How about by way of using a SQL list? I have to punch in for work but if there was some best practices that were easy to fire off, I wanted to test the waters before I spend time going into the specific nature of my portal slow down. 

 

As always, thanks in advance. 

[LaRetta]

Question:  Is it generally quicker to filter by relationships rather than the portal itself?

Answer:  ABSOLUTELY.  Portal filtering must evaluate ever child record to see if it should display it in the portal. 

 

Question:  Does filtering a relationship by way of a calc field slow the process?

Answer:  Possibly but usually not since you are talking about key field which is stored on the chid side.

 

Question:  How about by way of using a SQL list?

Answer:  ExecuteSQL() is (in current FM12 version anyway) slower than relationship (usually).

 

In addition to portal slowdown, other factors can be number of portals (including those on tab panels since ALL records on the layout are downloaded from Server and not just those being displayed on the current tab panel), complexity of the relational join (number of keys involved and whether non-equijoin) and even other items on the layout can make a difference (if FM needs to fully draw other complex objects and evaluate other calculations on the layout).