Duplicating Found Set

[Jarvis]

I am trying to produce a list of tasks for assembling kitchen cabinets. The task lists vary depending on what type of cabinet it is that we are building.

Whenever I select (perform a FIND) one type of cabinet, I get a list of all activities germane to that type of cabinet.

I would like to be able to duplicate all of these tasks (RECORDS).

The Records Menu provides me the option to DELETE FOUND RECORDS.

[color:red]Is there some way to duplicate Found records?

I would like to be able to grab a list like this, assign a unique cabinet ID number to each task, then give it to the guys.

Any ideas?

Thanks,

Jarvis

[eos]

I think the fastest way would be via a utility table which contains all fields whose contents you want to retain. It consists of the following steps

• obtain/calculate your new cabinetID

• set a variable with the new cabinetID

• perform your find

• switch context to utility table

• import with all necessary fields

• switch context back

• re-import

• perform replace field contents (current found set only contains the newly imported records, which is just what you want) on serial/ID field with variable containing the cabinetID

• do remaining stuff... ;-)

This saves you the hassle of writing a loop script w/ duplicating/omitting records on the way and keeping control of the record pointer ( a PITA...)

Hope this helps

cheers

eos

[Søren Dyhr]

There are several! But be warned ...not every duplication is relational healthy. The following tips does ONLY cover situation where stuff from earlier historic documents are needed to produce a new HISTORICAL document. It's important to know when we're speaking of a many2many in disguise and not!

Recursive relationships might solve this, but it's a very abstract topic to dive into, so I would instead suggest you download this template, allthough several newer than the fm5 tools used in this template can be utilized:

http://www.dwdataconcepts.com/dl/tm/Compile_INV2.sit

When the archive unpacks, choose all files and drag then "in a herd" over the FM8 application icon.

Another method is to simply use the Duplicate for each line and then in each new line change the foreign ID. Here comes in a handy trick you can read about here:

http://www.sumware.net/robfm/savingfoundsets.php

Which I as it happens just made a template utilizing - for another member of this forum. Investigate the template. What it does is that you set checkboxes for the stuff in a portal you wish to publish to other members, also by checking their names in another portal.

There is nothing snassy in the scripting beyond the way to save found sets. I've taken the liberty to use a constant which is a no-no, but what the heck it shortens the scripting - which by the way could be tightend considerably if you define the method recursively ...but the readability suffers from it - so I avoided it.

--sd

Royalties.zip

Edited April 3, 2006 by Guest
The importance of when to apply these tricks!!!

[Jarvis]

Eos & Soren,

Thank you for your fine responses,

I'm not sure yet if these will help me because, to tell you the truth, I haven't got a clue what you just said.

Perhaps I should work on my skill set then come back to this project.

Thanks again, Jarvis

[comment]

I am under the impression that indeed no duplication is actually required here. The task list is a constant, given by the job type. Any information about a specific job/task combination should go into a join table.

The constant task list can be displayed as slots, so that the additional information can be entered/displayed in the appropriate row.

Note that the viewer table is more than just a convenience: if users were allowed to browse the Jobs table, it would be difficult to synchronize the global gJobID with the currently viewed JobID.

CommonTasks.fp7.zip

[Søren Dyhr]

I am under the impression that indeed no duplication is actually required here.

Hence the initial cautioning I made!!

--sd

[Jarvis]

Hey guys,

This is starting to make more sense to me now.

Comment, that pull table was really useful.

I'm going to have to study your structure a little bit but it does present the data in a way that is unambiguous.

I'm thinking now of the FIELD FACTORY that LaRetta designed a year or so ago. The Viewer table could present task lists that were germane to the type of cabinet and each list would only show the tasks that were remaining per cabinet.

I know I'm on the precipice of something.

Thanks again.