Sorting dialogue on server side script

[sal88]

Hi all

 

Possibly 2 questions here.

I have a script that occasionally slows down if I run it locally, this is due to the fact that some layouts sometimes (I have no idea why - any suggestion why?) display the 'sorting records' dialogue box of which the script waits for.

 

Is it possible that this problem would occur when the script is run on the server?

 

 

Thanks

[Smef]

The script will fail if you include a sort with a dialog.  You'll have to disable the dialogs if you want to run the script on the server.

 

Check for script triggers on the layout if you're not sure why a sort dialog is popping up.

[LaRetta]

I believe you can also receive the sorting dialog when you are displaying records and the related table occurrence is sorted via the relationship (graph).

[Rick Whitelaw]

Regardless, show dialog is not supported on Server.

[LaRetta]

I have a script that occasionally slows down if I run it locally, this is due to the fact that some layouts sometimes (I have no idea why - display the 'sorting records' dialogue box of which the script waits for.

 

The 'sorting records' dialog is not a script step ... it is an FM-generated dialog which can appear on very large record sets when a sort is being implemented.  It can appear  (in addition to the regular Sort script step) when switching to a layout which has a sort on the relationship.  I don't believe we are looking for a script step at all which is why its appearance was perplexing to sal88.  I remember it perplexed me too the first time it happened.  :-)

It is probably true that it might not display if ran server schedule ... it's like ... if a tree falls in the forest and nobody is there to hear it, did it make a sound?  LOL.

But it STILL must sort the relationship if that is established in the graph ... whether server schedule DISPLAYS that dialog then would be interesting but how would we test?  Server schedule IS a client after all.  Maybe Open URL.

 

ADDED blue

[bruceR]

I agree with LaRetta that this is not really a dialog. It is not waiting for a user response. It is more of a progress message, which will not display in a server script, and as such does not affect server script performance. Most operations are much faster on the server anyway.

Sometimes I find that this slow-sort progress indicator is a result of a problem, perhaps a sort that is not valid for the current context, such as duplicating a sorted portal and pointing the portal to a new table occurrence but forgetting to update the sort.

[sal88]

It is probably true that it might not display if ran server schedule ... it's like ... if a tree falls in the forest and nobody is there to hear it, did it make a sound?  LOL.

 

hahaha good point.

 

But yes you understood exactly what I was getting at! Sorting in the relationship graph - makes sense now! I, and a few others are very happy now indeed!!

 

Thank you!

[Smef]

Ah, I understand now.  LaRetta was correct.  If that sorted relationship is important you could create another relationship and another layout which does not use record data from the sorted relationship, which would remove the need of the server to sort the records and would speed up the script.

 

Running the script on the server would be faster either way just because it doesn't need to send data back and forth to a client, so even though it would still happen it might be acceptably faster for you to do it on the server without making any additional changes to your scripts, layouts, or relationships.

[sal88]

Another scenario is where a layout that has the 'sorted relationships' issue is actually accessed by the end user (so not connected to any script), and the sorting is for portals that are on display. In this case would using the sort feature within the actual portal be preferable to defining the sort via the relationship?

[LaRetta]

It is my understanding that portal only pre-fetches the number of rows displayed but sorting must look at ALL related records to be able to sort so the process is the same whether in graph or on portal - ALL related records must be sorted to know which should then be displayed in the portal.  Sorting is resource-intensive regardless although much faster on server.  But if ran on server, the User doesn't need to see it anyway.  Understanding your User process would probably help here.  You can test and if server schedule, go to another layout like David suggested and run it there.

 

Another technique is to limit the relationship using globals.  In general, the smaller the related set, the more efficient.  Filtering using portal filter MIGHT help ...but only on more current versions of FM where FMS has been optimised in how it handles some portal filters.  Another thing you can do is decrease the number of fields in a table, remove any summary or unstored calculations from the portal and only sort on indexable fields.  

[sal88]

Understood, thank you!