I'v seen someone do it by clicking on a button which sends the seperated fields to the clipboard and you just paste it into a single field.
Hopefully that's only your perception, and not what actually happened. You should normally try to avoid the clipboard at all costs – using it may come as a nasty surprise to a user who will rightly regard their own clipboard contents as more important then some temporaray data; also, script steps that use the clipboard require the fields involved to be on the layout, which may or may not be the case (and often isn't even desired).
Use $variables and Set Field instead. e.g.
Set Variable [ $addressBlock ; List ( Customers::field1 ; Customers::field2 ) // etc. )
Go to Layout [ AnotherLayout ( AnotherTable ) ]
Set Field [ AnotherTable::targetField ; $addressBlock ]
The other question: why do you need these data on another layout (and, presumably, in another table)? Is this an invoice, and you want to capture the client data as a snapshot in time to guard against future changes?
In almost all other scenarios, setting a foreign key and displaying the related data is the way to go in a relational database.
1 of 1 people found this helpful
I agree with erolst that this sounds like a mistake to do with data. Proper database design should make this info available on related records via a relationship.
If it something like an Invoice, where you want to capture existing data at a specific point it time, even it were later updated in the source record but not in the Invoice archive, then you can do that with Scripted Set Field steps, where you use a calculation to set the values to be Set (not pasted) into a record's field.
This could also be done using Lookups (an auto-enter feature) for pulling/capturing data across a relationship when you enter the chosen client into an invoice, for instance, and the adressing info follows into the invoice addressing fields via the lookups.
Thanks erolst, took me a little while to get it but it works perfectly.