Slow Portals

[kilby]

Hello

I've created a database that archives all of our company emails. There are currently over 5000 records in the database. I've tried using a portal and a custom sort key for subject, email name & date. Sorting the portal can take up to 10 seconds or more, so its quite slow & painful to use. The custom sort key is a global field and is unstored so indexing can't be turned on for this field.

Is it that portals are just to slow for this and I should stick to list views? Or am I doing someting wrong?

Main reason I wanted to use portals, I can have a highlight field in a row, I can also multiselect rows (with a hightlight as well) and the interface is quite neat & clear.

Thnxs

Kilby

[Vaughan]

There are a couple of things that you say in your post that I don't understand, and that indicate some fundamental problems...

"The custom sort key is a global field and is unstored"

Global fields cannot be used for sorting, so something is definately amiss here. Sorting any unstored field is always slow, it's got nothing to do with the portal itself.

"Main reason I wanted to use portals... I can also multiselect rows"

This is news to me... only one portal row can be selected at any time, though you can use portal row selection tricks to give the appearance of multiple row selection.

[kilby]

Hi Vaughan

Sorry about the confusion. Your right the sort key which is a calculation is not global, but is unstored. The global field is just the field that the calculation uses to determine which column it is sorting, the date, name or subject.

As for multiselecting rows, yes this is the multi-key selection trick which I've picked off the web.

[kilby]

okay, I've also looked at various portal sorting techniques around. There seems to plenty of example files to download. They all use a unstored calculation as the sort key. So if I want to sort a portal, fast, in FM7, how do I do this?

[Ender]

You might use a different layout for each sort option, where the layout appears the same, but the portal is sorted by the corresponding indexed field. Not pretty, but it might be faster.

[kilby]

lots of layouts, means lots of work when trying to update interfaces or change functionality.

[Ender]

I know that, but you're the one looking for faster portal sorting.

[LaRetta]

So if I want to sort a portal, fast, in FM7, how do I do this?

Hi Kilby,

You might do it by restricting the number of related records. Does that portal really need to sort ALL of the 5,000 related records? Aren't Users sorting in various ways to bring their desired results to the top where they can see them? Surely they aren't going to scroll all 5,000. In fact, they are performing the sort to FIND. So you might consider providing filters.

You can have a nice global calc for the left key. They could enter a global date popup or range, which would display conditional global popup of associated email addresses (called conditional value list) which could provide global popup of associated subjects (if you REALLY want to drill down). Global multikey to standard field and regular global to multikey or any combination thereof. I rarely dynamically sort portals because I bring the information to the top (within easy portal scroll) for them then standard default sort is enough. So consider restricting the relationship further based upon their conditions (and you can stop the left key from producing ANYTHING until criteria has been selected so they can't sort before it's filtered). Dynamic sort (if needed at all) would then be very quick because it would be working on a small number of related. And multiple selection (and writing IDs to global key) can still take place just as well.

Just an idea ...

LaRetta

[kilby]

Hi LaRetta

Thats a great idea, it adds greater flexibility for drilling down to the right message and would speed things up tremendously.

FM7 also has much better flexibility for creating complicated relationship.

Thnxs

Kilby