I have a database that is structured like:

Client--->Jobs--->Items

I need a way to be able to take a series of Item records and copy them to another job. How can this be automated?

The usual way is to:

select the item records for the existing job

create the new job record

remember the new job id

go to the selected item records

duplicate each item record, giving them the new job id

If you're wanting to duplicate several records in a particular table, you have two options:

a) create a loop that steps through the records and uses the Duplicate Record script step to dup each record individually. This will necessitate creating a 'flag' field to manage the found set. Specifically your script will have to:

1) find all records and clear the 'flag' field

2) find the recs to duplicate and set the 'flag' field to '1'

3) enter a loop

4) duplicate record (this will be the first rec in the found set)

5) change any info you need to (i.e. the related many key, etc)

to make the new record associated with a different parent record

6) clear the 'flag' field for the new dupped rec

7) find all recs with 'flag' = '1'

8) exit loop if Get(found count) = 0

9) end loop

: the other option is to automate an import/export of the entire set of records. That is, find the recs to dup. Export them to a temporary file. Import the file. Change any relevant data in the current found set using the Replace command.

If the number of recs is large, then option : is probably the best.

Hope this helps. John

The folks at Six Fried Rice posted an elegant alternate solution to duplicating items in their blog:

Six Fried Rice

Requires an extra relationship, but allows you to specify which fields to SET in the new item record - rather than having to clear out all the values you don't want in the duplicated record.

This will necessitate creating a 'flag' field

Certainly not! A reverse sort order, a script paramter, a conditional autoenter value(s) ...and then double omit!

...and the relational sophistication suggested in the Sixfried link doesn't harm either, but their substantial setting of fields is IMHO fully justified only one might be in order. Here are we back in the conditional autoenter, since you selectively can make them perform via:

http://www.filemaker.com/help/FunctionsRef-262.html

--sd

...and the relational sophistication suggested in the Sixfried link doesn't harm either, but their substantial setting of fields is IMHO fully justified only one might be in order. Here are we back in the conditional autoenter, since you selectively can make them perform via:

http://www.filemaker.com/help/FunctionsRef-262.html

--sd

True, though at a certain level what we're all talking about is programming style, since all these methods work. You can make a style argument for the sixfriedrice method over a conditional autoenter that checks for the current scriptname (which I think is what you're suggesting), namely:

"I want all the process logic to be embedded in the script itself." Embedding the process logic for a particular script into fields means you need to do a bit more work as an outside developer to get a gestalt sense of what the script does.

That said, I'm a meat-and-potatoes programmer, and confess that I just do what Vaughan does: duplicate, omit, omit, repeat etc. If I need to clear field values I do it explicitly in the script. Elegant, I am not.

"I want all the process logic to be embedded in the script itself."

Which is rooted further back in the history of programming, where method weren't that tightly associated with the object. There is however a re-usability aspect to this, if the script logic is the same with all aspects in the solution, could more procedural methods be gathered in the one and same script, them being "Jack of All Trades":

http://web.mac.com/zueiv/iWeb/FileMaker/Script%20Killing%20Techniques/AFA363C6-2D85-4C6D-82E2-273F3722A69E.html

--sd

Yeah, okay, now my head hurts! Very cool.

We could have another one of these conversations on the topic of where process logic can be embedded, but I thing Crystalguy probably has enough to go on with what's been said, without 90 more posts :