Is there a way to determine what is causing our Database to perform random finds. I'm assuming that it has something to do with an un-indexed related field but is there a way to determine the actual cause?
We'll need more information. Some screenshots maybe? Also state the version of your clients and the server.
There is a known issue with the "find in progress" dialog coming up at seemingly randome times. If that is your issue then open a support case with FMI and report it here: Report a Product Issue
In the meantime:
1) make sure that none of your layouts use the 'classic' theme
2) assuming that you are on FMS 15 or later: toggle on the top call stats log and see what it reports as queries. That may give you clues as to what you can change in the design of your solution to avoid this.
We are using FM 16 on all client machines and FM16 server. All machines are running on Mac's. I don't think that we have any layouts that use the classic theme but I will go back through and make sure.
Yes that's exactly whats happening it just randomly comes up. I'll report the issue right now and I'll setup Top Call Stats on the server and update with what I find.
Screenshots of the entire screen would still be nice because that would allow us to see what is on the layout that makes FM think it needs to perform the query in the first place. If you have lots of portals or web viewers on the layout for instance, that could affect it.
Got it. Should I wait until the the Dialogue comes up again or take a photo of the layout as is?
either way is fine, but when the dialog does come up up, mark the time and go look at the top call stats log as quickly as you can for that timeframe.
Do you have a copy of FileMaker Advanced? And can you run a DDR? And do you have any of the DDR analysis tools; like Base Elements or FMPerception?
I have sometimes found this to come up when an out-of-context sort is specified for a portal.
For me, it happened like this. I copy over a portal; or change the context of the layout. The portal had a sort order specified.
But now - that sort order is not based on a relationship associated with the current table occurrence. The DDR tools can help you spot things like this, though if you know what to look for you can review portals one by one your self.
Having logged into a particular client’s hosted system for the first time in a while, we’re seeing this as well. Not sure if this is a factor, but their database is linked to an SQL database via ODBC On Windows 2012 R2.
Haven’t time to investigate further, as flying out to Austria for a ski trip in a few hours, but will need to investigate further on return. Perhaps linked to moving to FileMaker Server 16.
Do you have a large "spider" graph or use techniques like selector connector? Connecting up a lot of schema with cartesian joins and the like can cause this as your database grows.
I don't think that I use an Cartesian joins in any relationships. What is a selector connector?
That was a good idea. I checked all of my portals to see if I had an unrelated sort field and didn't find any. I'm going to run a DDR report now.
Could there be a script trigger that's firing? I inherited a system that had layouts which had been duplicated. The original developer didn't disable a trigger. The context of the layout had changed so whenever the user hit this layout it would invoke a search on non-related or really far-away related fields.
I was fighting this same thing last night as I was editing a script and testing it. My findings might provide a clue.
In my case, the script needed to access data in a related field immediately after setting a global match field to a value. The underlying relationships helped figure out why my changes were causing this "find" progress bar to pop up when it didn't previously.
Some one else mentioned Cartesian joins and that's exactly what seems to be a factor for me. My context when I was getting the dialog was NoData, a table that I use as the basis for an "all buttons" menu layout and which has only one record. The global field being set was a field in MainTable and used to "select" for a specific record in LookUpTable. Main Table has a very large number of records (about a half million and fairly "wide"). The link from NoData to MainTable is a Cartesian Join (x operator).
After watching the script in the debugger to determine which step was popping up this progress bar, I determined that my edits to the script had changed the layout context from MainTable to NoData. Putting the context back to MainTable made the dialog disappear. I suspect that the Cartesian join to massive MainTable was the culprit here given how simply disabling a Go to layout step specifying a layout based on MainTable was all that was necessary to cause this dialog to appear. These tests were run after hours when no other users were accessing the system so I could rule out the possibility that Frequent new records and edits to main table by other users were a factor in this particular case.
For me the next step is to experiment with using ExecuteSQL. to access the data from the LookUpTable. This table is small and almost never modified so I expect to have zero issues with using that function to get this to work and then I no longer have to concern myself with context for this particular part of the script.
Retrieving data ...