How to reassign a TO and preserve field names?

[K1200]

I've found a TO that is linked to the wrong primary table.

I want to keep the TO—same name and fields—and link it to a TO of the the primary table ... not the primary table, itself.  I can't determine a way to do that.  I learned long ago that if I create a duplicate TO, it generates a "2" version ... and I have to change all the references in scripts and on layouts.  Likewise, if I delete the original TO and generate a new one of the same name ... all the original references in scripts are lost.  Is there another way?  I tried adding a link to the correct TO, with the idea of then deleting the original link ... but it won't let me set two, even for a moment.

Even after 7 years, this is one aspect of FileMaker I've never understood.  (Please tell me I'm missing something!)

Thanks in advance for any help.

[comment]

I don't understand your question. A TO is an occurrence of a base table. It has no fields of its own - the fields are the fields defined in the base table. If you re-assign a TO to another base table, then it will show the fields of its new parent base table.

[K1200]

Yes, the TO is an occurrence of a primary table ... but the relationship diagram has it linked to a table that's different from the one I need it linked to ... so the portal that displays it doesn't show the correct subset of records.  I need to reestablish its relationship without disturbing all the scripts and layouts that reference it.

Possible?

 

Edited November 17, 2015 by K1200

[Fitch]

I think maybe this is the trick you're looking for:

http://filemakerhacks.com/2013/02/23/copying-and-pasting-layout-schema/

[comment]

11 minutes ago, K1200 said:

but the relationship diagram has it linked to a table that's different from the one I need it linked to

That's easy to fix: just double-click the TO and select a different base table. But this does not jibe with what you said earlier about keeping the same fields.

[K1200]

@Fitch: if I follow that method, it's remapping references as the layout is pasted.  But I'd be afraid to use it on my main layout that has 50 tab overlay panels and references probably 500 fields.  It's also a recently-converted layout from the fp7 side of the fence.  I'm skittish about introducing something that would take me weeks to ferret out.  Plus, it doesn't appear to address the script references.

None-the-less, it's good to know of and will come in handy on some of my simple applications.  Thanks.

 

@comment: thanks for the suggestion, but unless I'm not understanding, double clicking opens the relationship dialog, but doesn't let me delink the existing relationship.  Is there some other feature?

 

 

[comment]

3 minutes ago, K1200 said:

unless I'm not understanding, double clicking opens the relationship dialog, but doesn't let me delink the existing relationship. 

I am still not sure I understand what you want. If - as you said - you want to link an existing TO to another base table, then do what I said: double-click the TO itself (not the connecting line). Or select the TO and click the Edit button (the one with a pencil). Either of these will open the Specify Table dialog where you can assign the TO to another base table:

I am not sure what you mean when you say "delink the existing relationship". This has nothing to do with relationships.

[Fitch]

Maybe we're over-thinking this. Is your question just how to unlink a TO? Just click on the relationship line or the little "=" sign and hit the delete key. Then you can link the TO to the one you want.

[bruceR]

Tom, that part seems unlikely as the OP mentions the problem of relinking everything (scripts, fields in portal) and hopes to avoid that.

Like Comment, I am confused about how you he keeps saying he is linking to a different instance of the same base table yet everything is different.

[Fitch]

Seems like this might be an XY problem.

[Ocean West]

K1200 this possible I've done this there are two methods that come to mind 

method one:

1. Rename the base table to something else 
2. rename the other TO to what the base table name was.
3. Go to your layout (now based on the renamed TO )  copy everything 
4. Restore the table names to original names 
5. Go to layout and set it to the desired base - TO
6. then delete everything on layout
7. paste contents of clip board 

All the fields should now be based on the correct this to the underlying field names via copy & paste are based on the TO name not any internal ID

method two:

purchase and use clip manager then mess with the xml of the copied clipboard 

[K1200]

Quote

Someone asks how to do Y when they really want to do X. They ask how to do Y because they believe it is the best way to accomplish X. People trying to help go through many iterations of "try this", followed by "that won't work because of". That is, depending on the circumstances, other solutions may be the way to go.

@Fitch: you hit the nail on the head.

Four more hours of diligent testing arrived at the actual solution.  I won't bore anyone with all the details, but suffice it to say I had a TO related to a global field in a primary table ... and the relationship wasn't causing the displayed content to change when I changed the global.  I thought the solution was to relate the TO to a different TO that was always "current" with the operating circumstance.

What I've finally determined is that a Refresh Window[Flush Cache Join Results] is needed.  Before that, I tried adding a cartesian join ... as suggested by this article: Article

But the join didn't work (don't understand why).  The Flush Cache does.  So, I was looking for Y when I really needed X ... or is it the other way around?

Thanks for all the suggestions. 

[Wim Decorte]

14 hours ago, K1200 said:

my main layout that has 50 tab overlay panels and references probably 500 fields. 

First order of business: get rid of that layout!  Break it down into different layouts that are going to be easier on performance.

 

 

[K1200]

That IS on the agenda.  But the first order of business was/is to get the application fully working in FMP14.  It's come up all the way from FMP7, when you had to keep track of active tab panels with variables like $$Tab1, $$Tab2, etc.  I'm sure you remember that.  Many of those are being replaced with Popup Panels ... as time permits.  

All-in-all, I'm pleased with the way such a complex application is behaving under FMP14.  It certainly wasn't that way on a previous attempt ... an abandoned upgrade to FMP12.  In that instance, the GUI was badly mangled.  Now, it largely works (theme=Classic) ... with pretty clear reasons when something doesn't.

Thanks again for the suggestions.

[Fitch]

@Ocean West Stephen, that's the method in the FileMaker Hacks article that I linked.

[Ocean West]

@Fitch  yea i only realized that after i wrote the post - i was on my iPhone and didn't read the FMHacks post. 

[LaRetta]

I used this once long, long time ago when presented by Comment and it saved my bacon!  

http://fmforums.com/topic/46446-duplicating-a-table-wfields/#comment-216721