While Copy and Paste are valid script steps, I strongly recommend that you don't use them for this purpose. There is a better option.
Set Field [$VariableHere ; YourTable1::Field ]
Go to Layout [ "YourTable2" (YourTable2 ) ]
Enter find mode  ---> clear the pause check box
Set Field [ YourTable2::Field2 ; $VariableHere ]
Set Error Capture [on]
Perform Find 
For more examples of scripted finds, see: Scripted Find Examples
thanks so much... but is there a step before? When I try to create the Set Field step, I get this error...see screen shot.
Actually Phil... I think I got a handle on this. Thanks so much for your original post. (I marvel at how much service you provide on this forum. It's really great.)
For those "reading along at home":
When Setting up Set Field, there are two Specify buttons that must be clicked. To get Set Field [Table::Field ; Expression], add set field to your script and click the first button (specify target field). Select Table::Field from the list of fields. Do not click the specify button next to the repetition box. Click OK to close this dialog box. Now click the lower specify button (calculated result) and create the expression to the right of the semicolon (;). Do not try to type in the semicolon.
Phil, I've noticed that using "Copy and Paste" in scripts where Script Triggers are set (such as on Object Enter) results in feedback loops. If you use instead "Set Field" does that help to prevent such feedback loops?
Except for very rare cases, copy and paste should not be used in scripts at all. They have several draw backs, the worst of which is that users find any data they copied to the clipboard mysteriously disappearing each time that they run a script.
copy, paste, clear and the script steps that start with the word "insert" all interact with the field object on a layout and thus trip a number of script triggers. They also fail to do anything if the field object should be later removed from the layout. Set field does not interact with field objects on the layout, but modifies the data at the "data level" and this does not trip those script triggers. It will also successfully modify the data in a field even if that field is not placed on the current layout so long as the table occurrence context permits it.
That clarifies things. I've been building a complex (although simplicity is always my goal) for the digital version of my travel guide PLACENOTES. Do you work for Filemaker? Is that why you post so authoritatively and swiftly?
No, I do not work for FileMaker, but I was recruited by them to serve here as volunteer community leader. I've used Filemaker as a developer since FileMaker Pro 2.5.