Using find mode and empty found sets for faster layout navigation

[cjl]

Hello all!

I'm working on a very high latency solution. A server in Germany, clients in East Africa. I've a number of scripts that involve a (scripted) move to a different layout, record creation and a return to the original layout.

In an effort to speed things up, I've been trying to reduce the data requested from the server by entering find mode before switching layouts, getting an empty found set (say by searching for an empty key field) and then creating any records. If there's anyone who uses this (or a similar) technique and has some feedback regarding performance, I'd be very interested to hear about your experiences. And regarding this particular method, does anyone know of a table occurrence-independent way to obtain an empty found set? At present I'm tailoring each find request to a specific TO which results in some duplicate code.

Edited October 20, 2020 by cjl

[Steve Martino]

You stumbled upon a well known technique discussed many times on the forums regarding entering find mode. 

I don't quite understand your need for an empty set.  Are you looking for a record, then if you don't find it, you are creating a new record?

 

As far as duplicating code, this blog may help.

http://www.philosophyoffilemaker.com/robust-filemaker-design-87

Edited October 19, 2020 by Steve Martino
typo

[Fitch]

You're right to enter Find mode before switching layouts. However, if you don't actually need to find specific records, I'd recommend creating a blank layout for each table as needed for your scripted processes. A layout with no fields will not fetch any data from the server. This should be faster than performing a Find.

You might also consider opening a new window for the blank layout and then closing it -- switching layouts might have a performance cost. However, I would not recommend opening a whole lot of new windows, say in a looping script. That can slow things down.

Welcome to the forums. You might be interested in this:

 

[bcooney]

9 hours ago, cjl said:

I've a number of scripts that involve a (scripted) move to a different layout, record creation and a return to the original layout

You may refactor to avoid this by using the magic key technique or transactional scripting using a transactions table in a card window to create the record.

[cjl]

Steve, Fitch, Bcooney, thank you all for your replies.

Steve - I've not had luck finding a good discussion of using find mode to improve layout switching. If you know of one, would you mind posting it?
I had been looking to generate an empty set before creating a record in the hope that will reduce data transferred from the server. (i.e. no, not searching for a particular record) Thank you for the link. I am comfortable making TO independent field references, however the duplicated line is a 'Perform find' script step. I didn't know of any way to generate an empty set without tailoring this to a specific TO. However reading Fitch's reply, it sounds as though a blank layout rather than a null find is the sensible approach.

Fitch - thanks for the video. It's good to get confirmation that an empty field means no server - client data transfer. Yes, I do use 'new window using layout' rather than 'go to layout' script steps. Apologies for not making that clear. If moving to a blank layout, is there any additional benefit in doing so in find mode? I'd only been doing so to avoid loading any data from the destination table. If a blank layout solves that same problem, perhaps switching in and out of find mode is unhelpful?

Bcooney - thank you. Until recently I'd have used a similar (though less elegant) technique for almost all record creation. A TO and a relationship wherever I create records has left me with relationship graphs that are rather busy. Layout-hopping creation scripts for less frequently used processes seemed to me to be one way to simplify the relationship graph. But at heart, I just don't know the impact that a great many (say approx. 100) single-use TOs and relationships have on performance where there's high server latency. Do you have any insight into this?

[bcooney]

We have a dedicated file that is used for transactional create/read/edit and delete. It all happens in a window the user never sees. You can explore it in our framework, Karbon. https://www.geistinteractive.com/products/karbon-filemaker-application-framework/

There’s a lot there to absorb, but I suggest you focus on the kontroller file. You’ll see its RG is very simple. It allows for you to escape any ui concerns and focus on business rules. 

[LaRetta]

Creating a blank layout for each table occurrence (maybe calling each as:  Utility: Contacts or Utility: Invoices (etc) is very helpful for tables you're working in frequently.  As Tom mentioned, if there are no fields (no references) on these Utility layouts then records will never be fetched from the server even though the record-indicator may specify a number of records.  I include a message at the top reminding Developer to never place references on the UTILITY layouts.

As for isolating for a found set, a single utility script comes in handy because it is uncoupled, similar to script: ZeroRecords

Go to Record/Request [ first ]
Omit Multiple [ Get ( FoundCount ) ]

So scripts might be similar to:

Go to Utility: Contacts
Perform Script [ ZeroRecords ]
Go To Layout [ ... where you want to end with zero records in the Contacts table to begin creating your multiple records. 

There are other approaches as well. But really, without knowing the specific process you're expecting, we can't say for sure.  You aren't planning on looping and doing this multiple times, are you?  You just want to end up on a layout with zero records and then run process to create multiple records, right?

Feel free to share more information or your existing script if you would like further in-depth assistance.  

Edited October 20, 2020 by LaRetta