Using Blank Layouts to clear out Found sets (remedial question)

[Jarvis]

I have been reading (and re-reading) a Performance Guide created by the people at Filemaker.

 

This guide discusses an approach whereby the developer creates a series of blank layouts for each of the primary tables.

A script is triggered when a user first logs in that loops through the layouts and eliminates the found sets in each table.

 

Go to Layout ["A blank" (A)]

Show All Records

Show Omitted Only

Go to Layout ["B Blank"(]

Show All Records

Show Omitted Only

etc. etc

 

I don't know exactly how or why this works so for now I am just taking it on faith.

If someone could shed light on this or point me to a discussion about the concept I would be most appreciative.

 

MY SPECIFIC QUESTION is how do you navigate from this point?

Does the first script just clear out the found sets then link to a second script that takes you to a starting point screen?

[LaRetta]

The idea is that, without fields (or any reference to fields) on a layout, no records are fetched so having blank layouts is always very useful ... also for navigating through relationships using GTRR ... it is a fast-track method with no overhead.

 

The script you list would be part of your startup OnFirstWindowOpen script and would end with a Go To Layout [ your main menu ].

 

When the User then selects a table to begin work, you need to provide them with their opening record set (if any).  This is usually based upon the business rules of what a User wants to see, usually something like 'current work due' or 'this User's customers' which would produce a much smaller record-set.

[LaRetta]

One thing ... it would make more sense to do this:

Enter Find Mode [ uncheck pause ]
Go To Layout [ first layout ]
Set Field [ any text field ; "zzzz" ]
Set Error Capture [ On ]
Perform Find []

In this way, you do not need to show all records first and it should be even more efficient.

[LaRetta]

One problem with 'Show All Records' and then 'Show Omitted' is that, if another User has created a new record, it will appear in your 'omitted' record set. In this instance, it might not matter.  Neither have I tested which method would be more efficient so I might be incorrect.

[Jarvis]

Thanks LaRetta, .

I like your idea about using SET FIELD with SET ERROR CAPTURE.

[comment]

One thing ... it would make more sense to do this:

Enter Find Mode [ uncheck pause ]
Go To Layout [ first layout ]
Set Field [ any text field ; "zzzz" ]
Set Error Capture [ On ]
Perform Find []

In this way, you do not need to show all records first and it should be even more efficient.

 

If your purpose is to have an empty found set, wouldn't it make more sense to omit the current found set?

[LaRetta]

Oh my!  So simply do this:

Go To Record/Request/Page [ first ]
Omit Multiple Records [ Get ( FoundCount ) ]

That would be the best of all worlds, I think!!  I like that so much I'm going to adopt it - that is, unless you had another approach!  But this would eliminate the need of entering Find at all, eliminate error capture ... heck, it MUST be the fastest!

 

Thank you!  And if you had another way I would love to hear that also but this way rocks!!  

 

[Aussie John]

So back to the OP question does FM do a find on opening to match the last closed?

[LaRetta]

Back to the OP question?  I didn't think we ever left the OP question but it seems you are asking for clarity as well, John?  

 

Served files always default to show all records in all tables and the idea is to stop the pre-fetch of records just because (or when) a User accesses a layout.  By taking advantage of blank layouts (no references), we can establish 0 records at no cost.  This is huge impact upon User experience and latency.  It is suggested that at Startup OnFirstWindowOpen, tables which are accessed by Users should be set to 0 records by going to layouts without references (blank).

 

Below is a great video by Mark Richman of http://www.skeletonkey.com on Design Performance!!!

 

http://mfile.akamai.com/23543/mov/citrixvar.download.akamai.com/23543/www/808/384/4702939248581808384/517B5D544FF61100.mov?submit=View%20Recording&aliId=101923931

 

The entire video is excellent and EVERYONE should watch every minute of it (without doubt) as well as the associated PDF https://community.filemaker.com/docs/DOC-4168.  

 

Bottom line is ... how best can we control the unnecessary fetch and pre-fetch of data and objects.  This also includes wide versus narrow tables, using Freeze Window[] and other techniques to optimize.  We all struggle with these issues every day but particularly critical if WAN.  Comment in post #6 (illustrated hopefully in my post #7) adds another sweet tool to our toolkits. 

[LaRetta]

If your purpose is to have an empty found set, wouldn't it make more sense to omit the current found set?

 

Well, I provided one way but I decided to keep considering it anyway and here is another (although I doubt it is better, I will try to find time to test them):

Set Error Capture [ On ]
Constrain Found Set [ OMIT ; primary never-empty key ; * ] 

After testing - The above proved to be much slower in tests than Michael's suggested method, replicated in post #7.

 

:-)

 

Mark mentions Freeze Window in the PDF and confirms that it indeed stops data movement.  But then I question, why have scripts with both Freeze Window and Go To Layout [ 'blank' ]??  Is it 'belt and suspenders'?  If we can use Freeze Window then we should, according to theory, be able to bop about all we want and not download anything as long as we protect from script steps which cause a refresh or of course a field reference?  So what causes a Freeze Window to refresh?  Well, one unexpected answer is data viewer watch fields.  At least this is my story and I'm stickin' to it.  ;-)

 

Here is our discussion on Freeze Window with Tom Fitch where you reference our prior discussions with David Jondreau in my trying to grasp data movement with these various techniques.  

 

http://fmforums.com/forum/topic/94537-performing-find-in-a-script/?p=432527

 

I still don't have Freeze Window's behaviors nailed - mostly because when I try to test, I need Data Viewer watch open which forces the layout to draw and data to download.  It does not sit behind the freeze window when I'm debugging any more.  But that is one of a long list of things I want to post about.   BTW, top of page 26 of PDF is where it indicates Freeze Window stops data movement.

 

Oh such fun and so critical that we all understand how information moves between server and client.  I remember the first time I took a big file and served it LAN instead of working in it stand-alone ... I was shocked at how slow it seemed.  And I remember the first time I used a host provider and it seemed like I was drawing with chisel and stone slab.  I wanted to give up FileMaker IMMEDIATELY.  

[LaRetta]

BTW, using Constrain[] is much slower since it needs the index.

[Jarvis]

LaRetta,

 

I am so impressed that after all these years you are still learning new things in Filemaker.

I have often admired your self-description of "Lifelong FM Student".

Thank you so much. This is inspiring.

 

Jarvis