There are a couple of Warning Bells going off: I think the first suggestion would be "Tell us what you are using the repeated fields for because there may be a better way to design the system." Also if you could tell us what you are trying to achieve it is sometimes easier to offer suggestions.
But yes, there is no problem effectively copying and pasting the repeated field into a new record. You could, for example, capture all of the repetitions as $Variables (using the Set Variable script step), go to the new record, and use the Set Field script step to set each new field (or each repetition of the field) with each of the $Variables.
I second the extreme caution on using repetitions for data (if you are). Unless you are Master level in using FileMaker, don't use them. And even then most will recommend that you not use them for data.
Thanks for the feedback. Well, I'm hardly a Master Level at FileMaker but this forum is certainly helping me learn, so thanks to everyone for starters!!
Basically what I'm trying to do is a sort of "balance carried forward" type of thing from the current record into a newly created record... basically a weekly check sheet. It's not data that would ever be referenced again after the new record is created which is why I felt fairliy safe using repeating fields. I'll try messing around with the $variables, thank you.
But for the sake of argument (and my learning), suppose I had a list of items in a box. The box has to be inspected each week, and the quantity of each item and it's expiry date recorded. The list of items required to be in the box can change periodically from one week to the next (which is why I didn't use a value list). Essentially, I'm just looking to save the user from having to type in the contents of the box each week.
...and BTW, the $variable works perfectly. I didn't realize it would copy ALL the values in the repeating field. Thanks again Sorbsbuster.
Still not feeling totally at ease with this:
"Basically what I'm trying to do is a sort of "balance carried forward" type of thing from the current record into a newly created record... basically a weekly check sheet. It's not data that would ever be referenced again after the new record is created which is why I felt fairliy safe using repeating fields."
"It's not data that would ever be referenced again" - Famous Last Words. You will be amazed how useful your database becomes and how people will rely on it. I bet you it is looked at again.
"[It] is a [...] "balance carried forward" type of thing from the current record" - I would strongly recommend you re-calculate that balance on the fly as you need it. What happens when you change an entry that precedes the calculation (either listed before it or amended after the calculation was done)? Your users will be thrown when the apparent running total doesn't now match what they see on the list. And running totals have a tendency to... run. So when you set an error in there it just runs, and runs..."
"which is why I felt safe using repeating fields." - I don't any natural affinity between a running total and using repeated fields.
But, you know what your database does and how it is structured - it works, so good on you!
Well... basically what I have is a checklist 3 fields, we'll call them BOX::ITEM, BOX::QUANTITY and BOX::EXPIRY. On the "check sheet" layout, I have these set up to look like a chart so you might have a list that looked like:
apples 4 Jun 2011
oranges 5 Aug 2013
grapes 7 Sep 2011
pepsi 2 Dec 2013 (does Pepsi expire?? LOL)
All I need to "carry forward" is the first column (apples, oranges, grapes and pepsi) so the user doesn't have to type it in every time (the actual list is about 20 items). Rather than do a whole related table, I thought just 3 repeating fields would be easy enough so long as I could copy the values from BOX::ITEM to a new record. Am I over-complicating it?
So will you only ever have to check these 20 items?
If that is the case, you could simply have a script that duplicates the record and deletes all the irrelevant information.
You could have a Preferences Table where you set the record with the default values you want and set the Checklist to auto-enter those values when you create a new record. Then you could change Apples for Pears when your range is updated.
Still not happy, though. A huge strength of Filemaker databases is their flexibility and robustness, and this just feels like you are painting yourself into a box.
But you know your database best - go for it!