bcooney

Crest a new window and then do the find for the account. Close when done. 

Yes, DDR is the answer. Take it farther and use a tool that imports or reads the XML version of the ddr. Such as BaseElements, Inspector Pro or FMPerception. I work with FMPerception open as I develop to answer questions such as this immediately. 

Are the credentials cascading to the second file? Is the second file open on the client when you call the psos script?

Why are you creating a new TABLE for each import? Why not new records in a temp table.
 
And, no, you cannot script the deletion of tables or layouts.

The typical approach to this is to create a script that navigates to the layout that you want and assign it to the File Options perform script. Also, add a Close Script and have it navigate to the layout that you wish to view upon open.

Perhaps assign records to users (ownerID) and use rla view calcs?

Majit, there are several problems with your solution.
 
Here is a revised version. All you really need to do is store the foreign key for the primary address ID in Contacts.
ContactAddress2.fmp12.zip

Try OnLayoutLoad. Hmm. I'd throw a dialog to ask if they want to add a new record.
 
If (get(foundcount)=0
 Show Dialog, "Add New?", "Yes", "No"
  If get(lastmessagechoice) = 1
 Perform Script "Add New"
 Else
 go to original layout
endif

You need a join table Products>ProdFabrics<Fabrics.
 
Each record in the join table would store the unique combo of Product and Fabric to resolve what is called a many-to-many relationship.

@Anand - Yeah, get the terminology straight. Amazing you passed the FM10 certification without knowing the difference between the client and the server.

List ( ) with a self-join. But, where are you going with this?

I usual create a flag field calc that contains the logic I need for the "state" of a record, if possible. I use this flag in counts and finds. If I often need a find, and this calc is unstored, I create a stored version of this calc, and set it in a transactional script.