# Find in Progress Issue

**URL:** <https://the.fmsoup.org/t/find-in-progress-issue/4865>\
**Category:** Floating Topics\
**Created:** [May 21, 2025, 1:15pm UTC](https://the.fmsoup.org/t/find-in-progress-issue/4865 "2025-05-21T13:15:28Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Drew](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@Drew](https://the.fmsoup.org/u/Drew)\
**Post date:** [May 21, 2025, 1:15pm UTC](https://the.fmsoup.org/t/find-in-progress-issue/4865/1 "2025-05-21T13:15:28Z")

</div>

Anyone seen "Find in progress... Processing Query" pop up randomly in a FileMaker file? It happens even when no scripts are running or during scripts that don’t use Find steps. What could be triggering this?

---

<div class="post-metadata">

**Author:** ![bdbd](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bdbd/32/620_2.png) [@bdbd](https://the.fmsoup.org/u/bdbd)\
**Post date:** [May 21, 2025, 3:41pm UTC](https://the.fmsoup.org/t/find-in-progress-issue/4865/2 "2025-05-21T15:41:45Z")

</div>

Anything that looks for related records: portals; fields; calculations; etc.

---

<div class="post-metadata">

**Author:** ![Drew](https://avatars.discourse-cdn.com/v4/letter/d/b19c9b/32.png) [@Drew](https://the.fmsoup.org/u/Drew)\
**Post date:** [May 21, 2025, 7:52pm UTC](https://the.fmsoup.org/t/find-in-progress-issue/4865/3 "2025-05-21T19:52:10Z")

</div>

Thank you for your reply, I will look into this.  
There are tons of summary fields and calculations.

---

<div class="post-metadata">

**Author:** ![janhagemeister](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@janhagemeister](https://the.fmsoup.org/u/janhagemeister)\
**Post date:** [May 23, 2025, 12:40pm UTC](https://the.fmsoup.org/t/find-in-progress-issue/4865/4 "2025-05-23T12:40:41Z")

</div>

**The practical approach:** I’d duplicate the layout and then delete the objects one by one. That way, you’ll see exactly what’s causing trouble.

**The intellectual approach:** Look for fields that involve calculations or relationships processing data that doesn’t have an index.

Jan

---

<div class="post-metadata">

**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\
**Post date:** [May 24, 2025, 2:04pm UTC](https://the.fmsoup.org/t/find-in-progress-issue/4865/5 "2025-05-24T14:04:15Z")

</div>

> [@janhagemeister](#):
>
> I’d duplicate the layout and then delete the objects one by one. That way, you’ll see exactly what’s causing trouble.

Or even faster: use a binary search approach and delete half the objects at a a time, using Undo as needed to figure out the offending field(s).

---

<div class="post-metadata">

**Author:** ![daleallyn](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/daleallyn/32/819_2.png) [@daleallyn](https://the.fmsoup.org/u/daleallyn)\
**Post date:** [May 25, 2025, 8:59am UTC](https://the.fmsoup.org/t/find-in-progress-issue/4865/6 "2025-05-25T08:59:43Z")

</div>

> There are tons of summary fields and calculations.

Yes, I've seen it, and it usually alerts me that I've done something sloppy and need to adjust (as mentioned by others) certain relationships, unstored calculations, remove summary fields if not needed, etc. It often occurs (in my experience) when entering a new layout for which data must be collected, or possible navigating to a new record on the same layout where poorly designed script triggers update data on entry. Once one wrangles these events it be more performant and those messages will no longer occur.

I try to avoid, whenever possible, summary fields other than on reporting; especially in List view. In certain list view situations I hide the summary field (if it's needed, e.g. in a footer part) and add a button to "Show Summaries", so the user can show them when needed. A global $$variable is populated to set hide or show, triggered by various actions.