Changing Identical Field Names Between two Tables

[Jim Gill]

I have a table called Forms_2009 and another table called Forms_2010. Both tables contain identicle field names (Forms_2010 table was duplicated from Forms_2009 table). I'm going to duplicate the Layout Forms_2009 then switch the Layout Setup to Show Records From Forms_2010 and rename the Layout to Forms 2010.

Here is the question: Does anyone have a script that will switch all the field in the new Layout Forms 2010 (these fields will still be coming from the Table Forms_2009) to the identical fields in the Table Forms_2010?

I don't know how to begin to write this script and I'm sure there must be an easier way to do this other than manually changing all (over 100)the field names. Thanks in Advance!

Jim

[mr_vodka]

You should have both layouts be based on one table. What is the purpose of having two table?

[Jim Gill]

I have to maintain finacials (calc fields) from year to year (who still owes me from this year and who we owe) based on what forms they have submitted. I could use one table but then I would have to have to have seperate feilds for each year (E_Form_2009, E_Form_2010, etc). This would still require going into the layout and manually changing the feilds - not to mention creating all of those fields.

[mweiss]

I agree with all of the above comments -- but I have often found myself in a situation analogous to that of the OP: having created a layout based on one TO, I want to replicate it for another TO (of the same underlying table). And every time I need to go through and change the fields one at a freaking time. Is there a way to change all of the field definitions from one TO to another at one fell swoop?

[comment]

having created a layout based on one TO, I want to replicate it for another TO (of the same underlying table).

Why would you need this? I can understand a (rare) need for a layout based on another TO to establish a context for a script. But why would users need to interact with the table through this layout?

[mweiss]

Well, suppose for example you are working with a large file whose relationship graph is a spider. Maybe you've inherited this solution from someone who came before you... or maybe you developed it yourself before you knew better.

Now you want to restructure the whole thing using a more rational approach (anchor-buoy or other). But you don't want to disrupt functionality while the new TO's are being built and fine-tuned.

So, what do you do? Drop a few new anchors and start copying the existing layouts to them. String your buoys and get all the business logic right. Once it works, delete the old layouts and take the TO's on which they were based out of the relationship graph.

Surely I'm not alone in encountering this situation?

[comment]

I still don't see why any table would need more than one TO for data entry. Anyway, if you're unable to use the TO that already owns the layout as the "one", perhaps you could use the workaround described here:

http://fmforums.com/forum/showpost.php?post/222950/

[mweiss]

I didn't say I want to use more than one for data entry. I just said I want to replicate an existing layout to another layout based on a different TO. The context is as I described above: restructuring a relationship graph. In the initial stage, you have (just one) layout L#1 based on TO#1. When you're all finished, you have (just one) layout L#2 based on TO#2. In order to effect the transition, you need to replicate the layout and switch all fields on that layout to a different TO. (There may or may not be a transition period during which users are continuing to use L#1 while you're still setting up L#2.)

You know how a lot of people post here, and get replies that contain some variation of "You need to rethink your underlying data structure"? Lots of those people will find themselves in some version of this situation -- wanting to preserve an existing interface while they migrate to a better thought out relationship graph.

[mweiss]

Hey, that workaround is clever! Thanks for the idea.

[Jim Gill]

This is exactly what I was looking for!!!

Thank you!

Jim

[Jim Gill]

You know how a lot of people post here, and get replies that contain some variation of "You need to rethink your underlying data structure"? Lots of those people will find themselves in some version of this situation -- wanting to preserve an existing interface while they migrate to a better thought out relationship graph.

I bought this database with my business (meaning someone hacked their way through it before I did) and had to learn FMP in order to administer this thing. I've taken a few classes and now get by. DB administration is one of the many things I do (and I love it) but it's not what I do all the time. The nice thing is I don't have to convince some IT guy or other admin why I should deploy a certain solution - I am the IT guy. So anyway here is a link to my db (It's 13 Megs):

ftp://www.fernwoodcove.com/

FTP Login: fmp

FTP PW: fmp123~

DB Login: fmp with blank pw

Feel free to laugh, cry, criticize, comment what every you prefer. Know that if I have the opportunity to start from scratch I would do it a lot different. Anything that will help is much appreciated. Also know that I am looking to outsource a solution to add online accounts to this db - if you are interested let me know.

Thanks!

Jim

Edited August 3, 2009 by Guest