What version of FileMaker are you using?
This method works with all versions that supports variables:
Go TO Layout [table 2 layout (Table 2)]
Enter find mode  // clear the pause check box
Set field [table2:ID ; $$ID]
Set Error Capture [on]
This method works only with FileMaker 11:
Go To Layout [table 2 layout (Table 2)]
Set Error capture [on]
Perform Find [Restore ] //use $$ID as the criteria in table 2's ID field
I always perfer the first method as it is easier to tell what criteria is used in the find when I review the script in the script editor.
I agree with Phil
Using saved finds (without a way to address or edit the specific saved find) can be confusing to anyone trying to evaluate the script.
Another reason I dont like them has to do with possible changes that may effectively lose the saved status of the find.
Ive had issue with saved imports dropping the settings when a table change is made (even if its just adding a calculation or global field to a record) This caused the perform without dialog import to ignore the header record setting and the custom import order.
I would think that certain database or layout changes may do something similar to saved finds. This is not to say that you couldnt break an unsaved find script but at least if you did you would know what it was orginally so as to be able to fix it.
A "broken" saved find with error capture on that results in no records found could be giving you false impressions of the data in your database.
So to make a long answer even longer :)
I prefer to have the find critera in the script to ensure that I can better evaluate what went wrong when something invariably does :)
"Another reason I dont like them has to do with possible changes that may effectively lose the saved status of the find"
Not really an issue, the criteria are saved in the script. The only issues that would change the way such a find step functions would also affect the alternative method in the same way.
Scripted Imports are a different issue altogether and they do have a number of bugs that must be kept in mind when you use them though all can be avoided with a reasonable amount of care taken by the developer.
Well the issues that do effect them leave you with no idea what the saved find was to begin with. :) (especially when you werent the one who wrote the original script )
You can always double click the perform find step in the script editor to open it to review (and modify) the criteria used.
This was originally not the case. Back in the day, we used to have to run the script to perform the find and then use Modify last find to try and decode why the find didn't work as expected. That was the real pain and it was easy to miss criteria if you did this on a layout that didn't have the right fields present to show all the criteria used.
see you learn something everyday. Ive been so averse to using them that I never even bothered to see the change there.