To change tables you have to change layouts. You can freeze the window, switch layouts, create your record and then switch back to the original layout. And I wouldn't use the copy / paste script steps for this either. Copy destroys the current contents of the clipboard which can annoy your users and both copy and paste will not work unless the specified field is on the current layout.
Set Variable [$CustomerID ; Value: Customer::CustID]
Go to Layout [//select layout based on AD table]
Set Field [AD::CustID ; $CustomerID]
Go To Layout [original layout]
PS. I've thought for some time now that FileMaker needs a script step that establishes table context without changing layouts, something like:
Select Table Occurrence [//specify a TO in the relationship graph]
// include steps for working with this table here
End Table Occurrence
//context would now be returned to the current layout
I've suggested as much at: http://www.filemaker.com/company/feature_request.html
Any that agree can click that link and file their own similar suggestions.
Sorry, but FMP 6 does not have "set variable" capacity.
FWIW: I can't believe you cant script something as simple as copying a value, open a related db, create a new record and paste the value in an appropriate field, even in this older version. I will to make a layout on the Cust DB with a portal to the AD db and do what I want there. So it goes ...
Your suggestion is so basic, I have no idea why it hasn't been implemented. There no difficulty doing this in Access, but this needs to be built on a Mac.
Thanks for the answer, though.
Sorry, I missed the FMP 6 reference.
The basic technique still works, but you have to use a global field instead of a variable and two scripts, one in each file to make it work. The first script loads the global field and uses perform script to start the second script which is in the AD file. That script then creates the new record and uses a relationship back to the Customer File to access the global field's value. (Since it's a global field, any valid relationship back to that file will serve for being able to refer to the global field.)
Given those complications, manipulating a portal to create the record will be simpler to implement.
There's no difficulty doing this in Access
Well there's no difficulty in doing this in Access as long as you correctly manipulate the needed recordsets to do what you want. My suggestion, in fact, was inspired by my experiences with Access--which has many of its own failings but at least it doesn't require you to switch layouts just to gain access to a different table.
Thanks for your swift response. It makes sense to do it with portals.
I'm working on learning Mysql and hopefully skip some of the app specific nuttiness of mac and pc platform issues. I'm a middle-ground worker; I know just enough to get myself in trouble. I build an ambitious db every five years then promptly forget 90 percent of it while recovering until the next one. Again, thanks -- I'll be back before this one is done, i'm sure.