duplicate found set?

[DeAnne]

I have discovered how to manually duplicate a found set (to the clipboard only), is there a way to truly duplicate a found set & automate it for a script step? thanks for any help in advance ;-)

Edited December 1, 2009 by Guest

[Søren Dyhr]

Welcome to this forum, unfortunately have your provisions made it almost free to interpret your question as subjectively as one could wish. A reply can only hit in the vicinity of the desired when provisions of a context and purpose are given - I have here deliberately assumed the table structure as flat as a pancake - although including a unique record ID reflecting the records creation order....

Sort Records [ Specified Sort Order: Untitled::SerialID;descending ] [ Restore; No dialog ]

Go to Record/Request/Page[ Last ]

Loop

       Exit Loop If [ not Get ( FoundCount ) ]

       Duplicate Record/Request

       Go to Record/Request/Page[ Previous ]

       Omit Multiple Records [ 2 ] [ No dialog ]

End Loop 

Show Omitted Only

What it ignores or neglect is, that there might as well be related records?

--sd

[bcooney]

DeAnne,

As Soren mentions, you'll receive a better response if you would state why you feel it is necessary to duplicate records. Give us the scenario (context) and we can give you the best approach.

btw, duplicating records raises concerns about the data model.

[DeAnne]

the application is a Systems integration company, specifically proposals for audio video and control of sub systems (HVAC, lighting, etc) as such, many times, the items proposed in a room would be exactly the same as another (bedroom 1, bedrrom 2, etc) duplicating the found set for bedroom1 to bedroom 2 will be extremely helpful in insuring the integrity of the proposal.

very simply the relationships are client_ID > proposal_ID > area_ID > product_ID, achieved through multiple TO's to allow flexibility of viewing data (entire proposal, area at a time, phase of job, particular discipline aspect of job- Audio Video, lighting et al)

Thanks for the boost, I am hitting a wall with this one

[DeAnne]

Also- it's necessary to have the line items in the proposal as static rather than dynamic (they are look ups- ugh I know), the pricing and specifications change often enough that it would cause issues with previous and current proposals to allow them to be dynamic

[bcooney]

Fair enough. This link should be helpful: Ray Cologon's Duplicate Hierarchy Demo

[DeAnne]

Thank you- It's helpful in the text, I am using FM9 unfortunately and am unable to access the demo.

[Søren Dyhr]

very simply the relationships are client_ID > proposal_ID > area_ID > product_ID, achieved through multiple TO's to allow flexibility of viewing data

Not TOG's ??

BTW might you have decided on an inconvenient structure, might there be something to this perhaps:

http://www.filemakermagazine.com/blogs/tgantos/using-semantic-structures-in-filemaker-generalization-and-aggregation.html

http://www.filemakermagazine.com/videos/data-tagging-classification-vs-organization.html

...it could make the duping business slightly easier to deal with!

--sd

[DeAnne]

I apologize, TOG's not TO's

the video by Matt has principles I am already employing, in the 'view by' functions as noted in my previous post, however he clarified an issue, which will allow me a bit of distillation, much appreciated