Duplicating records using a loop

[Bikeman17]

Hi there,

Here is my problem. I got 15 records that I want to duplicate using a loop script. See my script:

Go to Record/Request/Page(First)

Loop

Duplicate Record/Request

Go to Record/Request/Page(Exit after last, Next)

End Loop

Go to Record/Request/Page(First)

The result is one duplicate only. What should I do get 15 new records?

[IdealData]

When you duplicate a record FMP creates it at the end of the current found set and then moves to that new record as well. Your "Exit after last" becomes effective immediately becuase you are now at the last record - hence only 1 duplicate.

Implement a loop counter (use a global field) to keep a track of your loop progress. Exit when you have got to the last of the original 15 records. You could also OMIT the new duplicate records each time.

[LaRetta]

Omit is much faster still if you eliminate moving to the next record. And you can eliminate the counter (additional field) which requires Set Field [] ... each of these steps decreases speed. Nothing dictates one must start at the beginning ...

Go To Record/Request/Page [ Last ]

Loop

Duplicate Record

Omit Record

Omit Record

Exit Loop If [ not Get(FoundCount) ]

End Loop

Show All Records

You will, however, lose your found set. But usually you can do everything to each record in the one pass anyway.

LaRetta

[Søren Dyhr]

I feel it should be mentioned that anything sounding the faintest like duplications, carries an inadequate knowledge to relational structures as stowaways ...only historic registrations such as invoices sounding the same as the previous seems in my ears to be valid exceptions to this rule. While making a quotation into an order containing exacly the same data seems unhealthy to say the least.

More info is required to justify your wish! Perhaps would your approach benefit from studying this template:

http://www.dwdataconcepts.com/dl/tw/compinv2.ZIP

--sd

[LaRetta]

Now, how did I KNOW you would jump on here and say that, Soren!!!

Let me give you an example.

Sales Manager creates a set of activities assigned to Mary. He specifies several field values (date of activity, time, importance etc). He then realizes these same activites should also be assigned to Jim. Everything is identical except who should complete the activity (which involves filling out several unique fields by User). Duplicate set and before first Omit (in my script example), set field with Jim's name (replacing Mary's). Over-simplification but you get the drift.

Duplicating is faster than creation of new record set and again setting all those fields and it does NOT imply poor relational. It saves time.

L

[Søren Dyhr]

than creation of new record set and again setting all those fields

Who's talking about the creation of a new set of records??? I'm talking about changing the foreignkey to make the same task show up in both persons portal of task, while the completion checkbox is a calcfield adressing yet another multiline key right next to the primary key ...do you need a template??

--sd

[LaRetta]

Once an activity is created, its date, time and every entry in every field is changed by each User. I think there is such a thing as splitting into related that is overkill and this would be one of them. I use multiline keys frequently but the comments and other fields would still need to be 'separate' unless I multilined them also. Overkill. Hard drive space is cheap. An activity record takes very little space. And by the time you add the keys when we're talking about 8 fields, the savings would be insignificant (and I don't like that word) because every bit of resource is usually significant.

So yes, maybe a demo will help me see your point more clearly because I'm not yet convinced, although I'm certainly open.

LaRetta

[Søren Dyhr]

time and every entry in every field is changed by each User.

Alright that's a good point, what I ment was that deliberate duplication into redundant data is daft, when it comes to it, waves the many2many relations flag somewhere in the horizon.

Multiline keys are substitutions for eventtriggers creation of join records, which is pretty handy and really fast when a number of virtual join records is either deleted or created.

I merely raised the question, because if it was duplication into redundant data - will it defeat the object with relational databases as such!

David Kaschel raised a very important issue in his whitepaper for novices:

Be very cautious when deciding to use specialized techniques in your solution. If they seem to require a lot of complicated coding, or manipulate FileMaker into doing something completely outside the database realm, you may be better off without them. If they add a slick feature to your database, but don’t really provide a significant functional advantage, pass them by.

This is why I always question to the purpose and if a proper relational structure is established, instead of throwing in a quick fix that either does what it's supposed to do or more likely not does!! The questioner must realize that being sparing with the purpose is likely give useless answers, such as these usual newbe question to repeating fields utilization.

The Whitepaper I refer to is:

http://www.codemastersworkshop.com/Downloads/WhitePaperForFMPNovices.pdf

--sd