Duplicating a table w/fields

[merkaba22]

Is there a way to duplicate a table and all the fields within it within the same file.

start with:

Table1 ... Table1::name1, address1

And create from this table and its fields:

Table2 ... Table2::name1, address1

I am sure there could be piles of instances this feature would be extremely helpful.....

Thanks

[Genx]

Yes, using FM advanced.

[comment]

Import the table to a NEW table in the same file. You don't need Advanced for this, only version 8 or higher.

[merkaba22]

That's great; in follow up if I want to use the same layout design in the second table as the first table, what would be the best order of action to minimize the amount of re-assigning field names to the correct table?

Ie, if I copy layout1 to layout2, the fields in layout2 will be assigned to table1 which would require clicking on each and choosing table2, etc.

Is there a way to avoid this since, in this case, there are over 75 fields in each table?

[comment]

Actually, there is a way: make a copy of your file. In the copy, delete Table 2 and rename Table 1 to Table 2. Go to the layout of what used to be Table 1, and Copy All. Now you can paste into a layout of Table 2 in the original file, and the fields will be assigned correctly.

[merkaba22]

Bloody brilliant!

Top rating Four Gold Stars to "comment" .... really:)

Thanks

[merkaba22]

The purpose behind the original request was to have a two layout/two tabled design, one each for Quote (table1)and Invoices (table2)so that by a key field , the quote number, lookups would populate the Invoice as the Quote. Works great.

In table1, address1::table1 was pulled over via lookup address1::table3 data when the name1::table was chosen from a drop down VL, etc.

I don't see a way to have address1::table2 pull from address1::table3 also when it has a lookup from table1 already?

I was thinking I could just keep address1::table 2 lookup from address1 in table2 where the VL for name1::table3 would come off name1::table1 as the Quotes data increases from real-world usage.

Any thoughts?

[Søren Dyhr]

Is there a way to avoid this since, in this case, there are over 75 fields in each table?

Hopefully will you be aware, that this seems to be a limping relational structure. That it will have top priority to "get the relations right" in the next incarnation of your app.?

--sd

[merkaba22]

The solution provided by "comment" worked beautifully and yes, it would be great if FM addressed this so that this important technique be more easy to render for all:)