Slow Portal Update

[ckai]

I'm just wanting to know if anyone has some suggestions as to way one particular layout would be updating slower than the others that are designed in a similar way.

 

The layout is pretty much only portals. 4 of them in fact. One is a navigation bar down the side (staff members), the other 3 display the relevant data from the selected staff member. Only 1 of these portals is used to enter new records.

 

The layout is based on my global table. Selecting a staff member updates, via script, the global staff id which the other portals are linked to by relationship (and other criteria).

 

The majority of the time, selecting a staff member for the navigation portal is pretty slow. I'm talking a couple of seconds. Debugging it seems to show that it's the Set Field step that is slowing everything down. Which I just don't get.

 

I use this navigation method throughout the whole database and the set field is pretty much instant. And the other layouts use more portals. 

 

The only big differences I can see between this layout and the others is this one is based on the global table and the others are based on self-joins. 

 

Would this slow is down that much?

 

This isn't really a "fix my database" question, it's more of a "what type of things can slow the layout down in this situation" discussion. Basically, I'm trying to avoid possibly doing anything detrimental in the future.

 

I am using the Refresh Window script step but not flushing cache. Normally I'd use Cartesian Join relationship to refresh the portals but I need the ability to create new records in the one particular portal.

 

I just find it quite interesting how performance can change dramatically based on a similar layout structure.

 

I'm all ears

[Matthew F]

Do you have unstored calculations that are based on the field being set by the "Set Field" script step? I'm guessing Filemaker is pausing to recalculate those values.  Or perhaps you have complex relationships based on this field... Or perhaps multiple windows open and filemaker has to refresh all of them? 

[ckai]

Do you have unstored calculations that are based on the field being set by the "Set Field" script step? I'm guessing Filemaker is pausing to recalculate those values.  Or perhaps you have complex relationships based on this field... Or perhaps multiple windows open and filemaker has to refresh all of them? 

 

No unstored calcs based off it. But you make a good point that overlooked with regarding Filemaker having to recalculate them. I do use a lot of unstored calcs in other tables and it's something I'll keep in mind for the future. It would have certainly explained the slowness if it was the case. All it is, is a simple global staff ID, which is linked to the staff ID for 2 other tables.

 

The relationship, at least to me, isn't complicated at all. I do have 2 tables based off the one global field but it's certainly nothing I haven't done already. My navigation list of staff members is based on a cartesian join to show all the staff members and the other table is a relationship shown in the attached screen shot. There's only one calculation in that relationship (flag_WageShiftCount) but it's indexed.

 

Definitely not multiple windows open. I create new hidden windows to perform complex scripts but they never stay open past the end of the script, and none are created when using this particular layout.

 

I might have to do some tests in using a self join table based on the staff members as opposed to the global table. But that just doesn't make sense to me. I can't see how using Set Field would be faster on a self join table compared with a separate table.

 

When using Script Debugger, once it has updated the global field the portals update straight away. Your suggestion of an unstored calc has got me thinking that somewhere, something is updating. I just can't think of what if it's not unstored.

 

I shall do some more digging. Cheers.

 

PS You are skier or boarder? 

[bruceR]

Are there sorts defined for the portal?. If you have a sort order not based on the portal relationship this can cause a big performance problem. Or summary fields in the portal.

Do you have calculated portal filters?

[ckai]

Are there sorts defined for the portal?. If you have a sort order not based on the portal relationship this can cause a big performance problem. Or summary fields in the portal.

Do you have calculated portal filters?

 

A few of the portals have sorts and filters on the display side. A few have sorts through the relationship. I just noticed one portal is sorted through the relationship and the portal itself. I think I was a bit eager getting it how I wanted!

 

One portal has a fairly decent calculation for a filter. It's used to display notes for clients. It no client selected it shows all clients notes, if a client gets selected it shows just those notes. You use the side navigation to select the staff member, that  shows shifts worked for the staff member. You can then select a client to show notes for that client and all shifts for that client during the period.

 

There are a few summary fields in 2 other portals that I actually missed counting since they're essentially hidden. I know they can slow things down as well but overall, this layout is pretty much a simpler version of my existing layouts they don't show the lag.

 

Are you saying it might not be the Set Field script step that's slowing things down and the actually display of the portals?

 

I might do the old test of removing portals to see what makes a difference. Actually, I may remove all the portals apart from the staff navigation list and show just the global staff ID field and see how quickly it gets updated. That will certainly narrow down that issue.

 

I will have to revisit the setups of my portals. I think I am a little lazy when it comes to sorting and filtering.