How about just before the Perform Find, go to layout that has the animated gif... freeze window, return to original layout and perform find? Not sure if that would work, but just an idea.
Personally I would work with the Oracle Database Indexes, as it would dramatically speed up the search process.
Searches on the Oracle db are instant. I use DbVisualizer to send query directly on the dbs and the same select takes less than 1sec on the database itself, while it takes about 2 mintues though the ESS.
I'll give it a try and will get back...
The challenge about Oracle Indexes is that you have no control of them in FileMaker and what you get is what the Oracle DBA has given you. I've had to complain a lot to them sometimes just to add indexes that we take so much for granted in FileMaker and it really does make a difference in search fields. Of course I could do it in SQL Developer, but they won't ever give me access. It just makes me appreciate FileMaker all the more.
Well in this case I am the Oracle DBA... so I have full access to the db. It is not a problem of indexes I can tell u for sure.
I don't know what the problem is, because I cannot look inside the ESS and see how it works.
It seems to me that the main issuse is relaying on ODBC which generally performs much worse than JDBC. Secondly must be something in the way FM itself deals with the linked tables, and thirdly must be an issue of what and how many data are sent to and fro the network to actually perform the queries.
I tried your diea, and the scripts now look as follow:
Go to Layout ["FIND" (ITEMS)]
Enter Find Mode 
Pause/Resume Script [Indefinitely]
Set Error Capture [On]
Go to Layout ["progress" (ITEMS)]
Go to Layout ["SIMPLE_FORM" (ITEMS)]
Perform Find 
Go to Layout ["RESULTS" (ITEMS)]
Now something wierd happens. In FMP it goes directly to the results page skipping the "progess" layout at all.
In IWP it hangs on the progess layout for ever. In the tool bar I can see that it actually performs the find and finds a set of records, but it hands on the progess page.
This is more of what I was thinking more along these lines:
Go to Layout [ “FIND” (ITEMS) ]
Enter Find Mode [ ]
[ Pause ]
#Load all the search fields into variables
Set Variable [ $Search Field1; Value:ITEMS::FIELD1 ]
Set Variable [ $Search Field2; Value:ITEMS::FIELD2]
Set Variable [ $Search Field3; Value:ITEMS::FIELD3 ]
#Go to Progress Layout -- animated GIF or whatever - make sure Layout is based on same Table Occurrence as the Find Layout
Go to Layout [ “PROGRESS” (ITEMS) ]
#Go to Find and Reset Find Fields --- Gets us back to the orginal Find state
Go to Layout [ “FIND” (ITEMS) ]
Set Field [ ITEMS::FIELD1; $Search Field1 ]
Set Field [ ITEMS::FIELD2; $Search Field2 ]
Set Field [ ITEMS::FIELD3; $Search Field3 ]
#Perform Find and then return to Original Layout
Perform Find [ ]
Go to Layout [ original layout ]
There are some optmization ideas to remember when working with ODBC. One is to just make an ODBC connection that is not ESS. I think that will go faster, but often is not as convenient as ESS. Another is to use ESS, but perform scripts on a blank layout that does not display any fields and only after ending the script, return to the layout that has fields on it. Another thing to remember is that with ESS, FileMaker creates a Shadow table and that causes overhead that probably results in reduced speed.
You might want to check out these progress bar examples for FileMaker, which are generally updated by script steps setting $$Variables at certain progress points. This is good for a long script, but not for individual steps that take a long time like the perform find above: