Ask for no records

["... you mean these fans?"]

Hi,

 

I am having trouble searching the internet …  "How To Ask Filemaker" to send zero records when I goto a certain layout without going into "Find Mode".  Currently I get "All Records" as the default.  And the internet is providing only general "Find" request links.  No luck with a "No Record Find" request.

 

Is this at all possible … Goto Layout "XYZ - [ No Records ]

 

I discovered through the recent webinar on "Performance" that I can go into "Find" mode, then goto the layout I want, then enter a date in the future.  Only because the user has yet to enter a future date. And I get my zero records.

 

I need a better way going to my layout asking for zero records … initially.

 

Thank you.

 

Tom

 

 

 

 

 

[Kris M]

My first thought would be to use the go to related records script step across a relationship that always has zero matches in the destination Table Occurence

[David Jondreau]

Use an onLayoutLoad script triggered script.

That script would be simply:

 

Show All Records

Show Omitted Only

[Rick Whitelaw]

David, would not that script be an unnecessary load over a network or from FMS?

[LaRetta]

Hi Tom,

 

It seems to me that showing all records is no different than performing a find and actually, it then pre-fetches 25 records (if form view) or however many records are displayed if list or table view so it just wouldn't be very efficient.

 

Why are you so against Find Mode here?  I guess it is not clear to me.

 

If you have a layout where you always want to begin with 0 records, then why not find something which can't possibly exist?

Enter Find Mode [ uncheck pause ]
Go To Layout [ your layout which displays the table to search ]
Set Field [ any field ; "==~~" ]
# the above is a value which cannot exist
Set Error Capture [ On ]
Perform Find

You will have no records and it will be a cheap way to get there.

[comment]

Set Field [ any field ; "==~~" ]

 

Isn't this (performing an unindexed find) like a cow that gives a pail of milk then kicks it over?

[LaRetta]

Oh good grief - you are certainly right!!!  You don't need to use == ... I was sloppy; it just must be an impossible value such as "#^U$KDKD" .  Thank you for catching that spilled milk of mine!  

 

And to explain, exact match search (==) does not use the index.

Edited November 5, 2014 by LaRetta

[David Jondreau]

David, would not that script be an unnecessary load over a network or from FMS?

No, why would it? Because FM loads 25 records in List view? I guess if that's a concern, you should probably put a Freeze Window at the start, that would take care of it.

["... you mean these fans?"]

Hi LaRetta,

 

I have a custom with an extremely slow network.  Looking inside the country for a reliable server was not an option. Had to look outside the country and we knew of the issue in the beginning with only a few records.  But as the file got to only 1000 records, and taking five minutes to load "A" invoice on the invoice layout ...

 

… we are being forced to call no data, then allow the customer to search by a specific parameter.

 

And yes I could also look at an impossible value through a relationship too … 

 

Thank you :-) everybody :-)

 

Tom

["... you mean these fans?"]

Hi LaRetta,

 

I have a lot of "Goto Layout" script steps.  And I thought that maybe there could be a better, easier way.  Like a one line script step :-)

 

I like "Find" mode.

 

And now that I'm am being force to be efficient, I am liking this "No Record" find concept even better.

 

Thank you LaRetta :-)

 

Tom

[LaRetta]

Hi David,

 

Freeze Window in 13 has been greatly improved and now "works as it should" per Andrew Paulsen but I did not think it stops records from loading but rather It stops the display from re-drawing (hides the actions from users) and that is its great speed savings.  The sequence is:

1. Prepare to build the layout
2. Fetch the data for the layout
3. Draw the layout

... but then I've also heard that 'data is not fetched until it is drawn' which fits with possible new Freeze Window (in 13) behaviour.  I would love to learn more about this if you can expand a bit. :-)

 

Walking debugger on the following script ...

 

Freeze Window

Go To Layout [ the layout ]

..... can you see any data at this point?

Show All Records

Show Omitted

 

... if you can see data at that point,  it means records have loaded.   So far I've only discovered using an empty layout (no references) bypasses record load and so does find mode.  Freeze Window would stop the next two steps (in bold) from being displayed to user.  Well, this is my current understanding of it but enhancements to later versions of 13 are still being discovered (by me) every day.   Thank you for the discussion!

[LaRetta]

And now that I'm am being force to be efficient, I am liking this "No Record" find concept even better.

FileMaker doesn't make it easy on us and I understood your desire. FM always wants to give us all records and expects us to drill down. Some developers actually loop all tables upon file open, using empty layouts so no records load and then leaving all tables on 0 records; many PROHIBIT Show All Records and it is rarely needed when you think about it. It always makes more sense to start with none and find what you want. It's like walking into a grocery store and having the entire store's contents piled on your head when all you wanted was bread!

Empty layouts are cool for quick GTRR through the bi-directional relational pipeline without downloading a single record - LIGHTENING fast. But when switching layouts, I prefer method mentioned - I read it *awhile back about entering find mode first which means NO records load upon entering the layout. It is simple to script which you want (zero records so enter bogus value on an indexed field if possible but at least a stored field) or (specific records in your regular search) ... both would begin the same way - Entering Find Mode[] before **going to a layout.

* I am sorry I do not remember where I read it. It was one of the top websites/developers or a webinar or Product Conference ... I read so much until half asleep/blind and I don't always get them earmarked.

** This means you must consider any triggers which are based upon mode change of course but since this is consistent and standard process, it hasn't been a problem. And when working, it will quickly become automatic.

Oh! Also David ... I forgot to mention, of course records are not loaded if all fields are hidden etc.

[LaRetta]

Hi David,

 

In post #11 above, I stated that I believed Freeze Window[] still created record movement (because you could see the data) but the attached supports your statement.  

 

 

The Freeze Window script step tells the client to not render the changes that would otherwise be displayed on screen. Even if there were fields on the target layout, they would not be drawn while the window is frozen, and therefore could not trigger data to move.

 

But then ... if this is true, why not always just use Freeze Window and drop the various concepts and techniques of going to blank layouts or entering find mode before switching to a layout?  

 

Freeze Window

Go To Layout [ a layout ]

Enter Find Mode[] ...

 

If it is behind a Freeze Window[] then this script step alone should stop server-to-client record load, shouldn't it?  I wonder sometimes if I'm getting fooled by what I can see when debugging.  I swear it's tripped me before. 

 

Anyway, thanks for sending me off in search of clarification for us!  It is important that the printed word (and spoken word) be as accurate as we can muster.

 

corrected #12 to #11

design_performance_fm13_en.pdf

Edited November 25, 2014 by LaRetta

[Mark Scott]

Hi LaRetta,

 

Freeze Window in 13 has been greatly improved and now "works as it should" per Andrew Paulsen but I did not think it stops records from loading but rather It stops the display from re-drawing (hides the actions from users) and that is its great speed savings.  The sequence is:

1. Prepare to build the layout
2. Fetch the data for the layout
3. Draw the layout

... but then I've also heard that 'data is not fetched until it is drawn' which fits with possible new Freeze Window (in 13) behaviour.  I would love to learn more about this if you can expand a bit. :-)

 

Andrew mentioned the improvements in Freeze Window at his DevCon talk, where he also described FM's "lazy loading" model.  The latter point was reiterated by Adam Ward, then again in a performance panel session (which both of them sat in on).  The sequence that I carefully jotted down matches yours.  Per my notes, FM: (1) loads parts and objects, (2) creates views for visible objects, (3) skips building views for non-visible objects (e.g., objects on hidden tab- or slide-panels or popovers), and lastly (4) renders views back to front, fetching data needed for those views only at that point.  One use for this is that related data on a hidden panel can be kept from loading until needed (provided, of course, that not a single field from those related records is on a visible part of the layout!).

 

…many PROHIBIT Show All Records and it is rarely needed when you think about it. It always makes more sense to start with none and find what you want. It's like walking into a grocery store and having the entire store's contents piled on your head when all you wanted was bread!

 

Or like Amazon's website!  Imagine going to their homepage and seeing a list of all gazillion items in their online store right off the bat.  On the other hand, we're all used to data-driven apps in our everyday arsenal that do treat the "all records" state as a default or "home" state—the "Inbox" in email clients, the "songs" tab in iTunes, the "Library" or "All References" item in the sidebar of academic reference managers, etc.—so countering that common expectation and designing for efficiency can be challenging (albeit worthwhile).

 

Mark

[Mark Scott]

Oh good grief - you are certainly right!!!  You don't need to use == ... I was sloppy; it just must be an impossible value such as "#^U$KDKD" .  Thank you for catching that spilled milk of mine!  

 

And to explain, exact match search (==) does not use the index.

 

Hi LaRetta (and Comment),

 

This caught my eye immediately the other day, as I'm working on a new approach to a scripted Find routine and had incorporated a == search into the code. Being concerned (always) about performance, I worried I've missed an important point along the way.

 

If I may ask, I wonder where this info comes from originally. Not that I read your comment and thought it to be wrong, mind you; rather just that I didn't know one way or the other, until your post sent a (small) shiver up my spine. Long story short, you set me on a Thanksgiving weekend journey of investigating the interplay of Find operators and creation/use of indexes in searching. Since it's a bit off the original topic, here, I've posted my methods and results in a fresh thread over here. Take a look, if you're interested, and post up with any thoughts, questions, or methodological flaws in my testing. My results seem to suggest that indexes are always used, when available, even when the search used operators such as ==, " ", and others. I even threw your ==~~ search against my test file, as you'll see in the table attached to the new thread. I'd love to hear your insights.

 

Thanks, btw, for always keeping us on our toes.

 

Mark

["... you mean these fans?"]

Hi,

I originally started this post and entering "Find Mode" has help however if it is possible to get some additional input on the following issue I would be grateful.

Apparently, when I go into "Find Mode" first, and then navigate to my layout, "Filemaker" still wants to sort all my records, before I even commit to a parameter ...

Please see attached pic.

Can anybody see what would cause "Filemaker" to sort at this stage of my script ??

Thank you.

Tom

 

[David Jondreau]

Snozzles,

You should probably start a new thread for this.

It looks like unusual behavior. Do you have other windows open? Do you have an OnModeExit script?

You can get this dialog if portals are sorting, but that shouldn't happen in Find Mode. Are you sure you're in find mode when this dialog pops up?

LaRetta,

I must have missed the continuation of this thread somehow...I would certainly add that a script running in the script debugger does not 100% match the performance of that script without the debugger. Freeze Window is definitely one issue (it doesn't actually work in the debugger) but also Pause/Resume, and some other steps I've bumped into over the years.

I'm not sure of a better test to see if local data is loaded when Freeze Window is followed by a layout switch, except using Wireshark or eyeballing the layout load speed for a table with big records.

*I posted this as two replies, but the forum combined them...is that expected behavior?

Edited August 19, 2015 by David Jondreau

[LaRetta]

Hi David,

I haven't been getting emails of posts or private messages, sorry I missed this.  Thank you for the additional input.  I've meant to start a new thread on the subject but just haven't had the time yet.

And yes, the forum combines messages if within a certain timeframe (a few minutes or so).

Hi Tom, I'm sorry, I just got home and won't have a chance to even review your needs right now.  Hopefully someone else can dive into it for you.  :-)

["... you mean these fans?"]

David, LaRetta,

Hi and thank you for you input.

David - yes I have a portal.  And yes when I remove the portal ... move off the visual screen the short does not happen ??

I have to show my customer records sooner or later.  If I show "No Records" my customer response is this.  We don't know what we are looking for ... but we know this .... ? so I had to give them something.

This is insane here.  

So I guess I'll have to default the portal a "Empty" state

If I build a portal based off of a global field I would keep empty until the customer initiated the entry would that prevent "Filemaker" from loading the portal.  I would think "YES" since the global is empty the portal can not build.

I will test this and let you guy know.

Thank you

Tom