Portal slowing down

[stefangs]

This will be lenghty, please bear with me!

In 'portalizing' my scheme, I want to use a single layout where I can do most everything. It contains multiple portals (inside a tab set with more stuff that's not related to the problem I think).

The first portal (shops) points to the currently focused table with an x relationship, so all shops are shown. From here, I want to be able to display contacts (customers), orders, and line items.

It is supposed to work like this:

Click a shop in the shop portal to select it - matching contacts are shown in the next portal.

Click a contact in that portal - matching orders are shown in the next portal.

Click an order in that portal - matching line items are shown in the last portal.

All this already works quite well, BUT when I switch shops there's a noticeable and annoying delay until the contacts list refreshes depending on the number of associated contacts. Clicking on a contact is also quite slow. The delay is about 3-4 seconds. The largest contacts table has only about 750 records, so nothing outrageous.

The problem, as I see it, has to do with how I set up my relationships. I want to be able to filter the contact portal dynamically and used the code from eos I got here (2nd post):

This filtering works, but it does not seem to allow record creation, therefore my relationship looks like this:

shops::ID_shop = contacts::ID_shop (allow record creation). This portal does not appear on the layout, records are created via a script on another layout.

The contacts portal on the actual layout is then filtered with the above mentioned setup as suggested by eos:

contacts::ID_shop = contacts_filter::ID_shop AND

contacts::gfilterBegin =< contacts_filter::contact_name AND

contacts::gfilter_End >= contacts_filter::contact_name

From then on, I move on to orders and line items which works ok. It looks like having two relationships of the contacts table in sequence following the shops table is bad design. RIght now, I'd prefer to give up the filtering to get better performance, but I don't want to rule out the filtering just yet and hope that someone has a suggestion.

Thanks for reading,

Stefan

Edited April 22, 2015 by stefangs

[bcooney]

Stefan,

Is your profile accurate...are you still on FM10?

There are techniques that are FM13 specific that I would suggest.

Look at this technique from Todd Geist: https://www.geistinteractive.com/2014/11/21/filemaker-selector-connector-video/

I found QuickFind faster for me. I go to a layout for the QuickFind and capture the found primary IDs using the new List Of summary field.

Here's one from Jeremy Bante: http://www.modularfilemaker.org/module/auto-quick-find/ that is in List view.

Edited April 22, 2015 by bcooney

[stefangs]

Yep, I'm still on FM10.

I do have a v13 license, but I can't use it, because my MacPro won't install it, even on a Mavericks partition! Thanks Apple.

Thanks for the links though. I'll check them out regardless.

 

Stefan

[Rick Whitelaw]

What you describe about not being able to install 13 is incorrect. I have 13 advanced running on my desktop machine which runs 10.7.5. When you say "Mavericks partition" this twigs me that something isn't right. Why would you have such a partition?  What is your startup drive? Which OS? I don't believe it's possible to run different instances of Mac OS on the same machine. So your backhanded "thank you" to Apple is almost certainly misplaced. The fault lies elsewhere.

[Wim Decorte]

This will be lenghty, please bear with me!

In 'portalizing' my scheme, I want to use a single layout where I can do most everything.

​Stop.

Bad approach.  It means that you will have one context where everything needs to be related to everything.  I don't know how much data you have or how complex your schema is but this will not be scalable.

Where did you get this idea and what is the perceived benefit?

[stefangs]

What you describe about not being able to install 13 is incorrect. I have 13 advanced running on my desktop machine which runs 10.7.5. When you say "Mavericks partition" this twigs me that something isn't right. Why would you have such a partition?  What is your startup drive? Which OS? I don't believe it's possible to run different instances of Mac OS on the same machine. So your backhanded "thank you" to Apple is almost certainly misplaced. The fault lies elsewhere.

​Rick,

it was late last night. What I meant to say was that I cannot install FM because I cannot install a later than OS 10.6.8 on my early MacPro. AFAIK, 10.7 is not available any longer. Trying to install Mavericks aborts - not supported! By separate partition I did't mean different instances simultaneously. It's possible to boot into a different system from a partition on the same hard drive. Nothing backhanded here, I appreciate the links.

Stefan

[stefangs]

​Stop.

Bad approach.  It means that you will have one context where everything needs to be related to everything.  I don't know how much data you have or how complex your schema is but this will not be scalable.

Where did you get this idea and what is the perceived benefit?

​Wim,

having one context is actually what I like. All data is supposed to be related to 'shops'. Every customer, product, order, etc. should be connected to a shop. Having it on a single screen makes it very easy to shuffle through the data for me.

shop>contacts>orders>line items

shop>contacts>mailing lists

shop>products>history

shop>mailing templates

This is certainly not the only way if doing it. In fact, I used to do it differently, but it was getting complicated and I am trying to merge my data in a way that makes sense to me. From a design point of view, this suits me perfectly. How will this not be scalable?

I think if I were to kick out the filtering portal, I'd be all set. Just thought that perhaps this can be kept somehow, because it's nice to have. Right now, the graph along this path is

shop>contacts>contacts_filtered>orders>line_items

I *think* that having the customers table twice between shops and orders is what creates the problem.

Stefan

[Wim Decorte]

​Wim,

having one context is actually what I like. [...]. How will this not be scalable?

​Because you are making FM work harder than it has to to display simple found sets.  You are already stating that the portal slows down and you're just getting started.  When you add more functionality, more records and more users, the performance will get exponentially worse.

[stefangs]

​Because you are making FM work harder than it has to to display simple found sets.  You are already stating that the portal slows down and you're just getting started.  When you add more functionality, more records and more users, the performance will get exponentially worse.

​Yep, I absolutely see what you mean. But it's still not quite the point of my post. Here's what I just did to be sure. I made a copy, deleted the intermediate filtering relationship TO, and reconnected accordingly. Which means there is just as much stuff to display in portals on my layout, but the underlying graph has one less entry.

portal shops > portal customers > portal orders > portal line items

The response is instantaneous. This shows that having two instances of the same table connected to each other for filtering purposes creates the problem. This is what I was hoping to fix with perhaps a better way to filter. But if there's no cigar, I'll just forget about the filtering.

[Rick Whitelaw]

​Rick,

it was late last night. What I meant to say was that I cannot install FM because I cannot install a later than OS 10.6.8 on my early MacPro. AFAIK, 10.7 is not available any longer. Trying to install Mavericks aborts - not supported! By separate partition I did't mean different instances simultaneously. It's possible to boot into a different system from a partition on the same hard drive. Nothing backhanded here, I appreciate the links.

Stefan

​Stefangs, now I understand. Will not Software Update go to 10.7.x? I don't remember if Lion was a paid update. I wonder if Apple Support could help. If your machine will support 10.7.5 and you can somehow get it then SMP 13 will run fine.

[stefangs]

​Stefangs, now I understand. Will not Software Update go to 10.7.x? I don't remember if Lion was a paid update. I wonder if Apple Support could help. If your machine will support 10.7.5 and you can somehow get it then SMP 13 will run fine.

​Yes, Lion was a paid upgrade. I can try  Apple support, but I have a feeling they want me to buy new hardware