This is not really necessary, but I'd like to know if it can be done....

Can a portal's relationship (ie: what table it's related to) be changed dynamically - by a value list for instance.

I have a multi-table db and am using the portals to display info only (data entry is via other layouts) from various tables. I have several portals on the one layout displaying info from various parts of the db - this takes more room than I'd like, and it would be good to have one location (one portal) displaying info from various tables.. Obviously I can't have the portals stacked on top of each other - but if I use only one portal, can the relationship of the single portal be changed dynamically to reflect the various tables being accessed?

The setup I have is running just fine as is - but I'd be intrigued to know if this can be done.

No. But you can go to another layout with a different portal - sort of like tabbed interface.

Obviously I can't have the portals stacked on top of each other - but if I use only one portal, can the relationship of the single portal be changed dynamically to reflect the various tables being accessed?

What about a change into a duped layout, each having their own relation shown?? This can be performed unelegantly by the plugin here: http://www.softs4humans.com/FMPro_Plugins.html where you after the download rush down to S4H QuickJumpMenus ...downloads it as well!

But say it won't work is there two things to consider here! Are the tables similar like say suppliers and customers addresses ...if so wouldn't I hessitate to merge them into one table with a multiple condition keying.

The second issue is if they can't be merged - the creation of new records if the tables field labels are nowhere near each other ...Then it can be done by pushing in an extra table in between, and the GetField function. This means again you have to make unnoticed (by the user) changes in the layouts ...because the creation has to be done in the separate layouts! Checkout the upload, which erronously assumes that the labels have the same names...

Queue will consider it overkill to mentioning this, but it seems to me that something in the relational structure you suggest, lacks something to be desired - I have never been impressed by the funfair effects the plugin allows??

--sd

MultiInOne.zip

Using standard techniques - no. But ther are ways to "roll your own data structure" where TableID is a field in each record. If you use this method you can make surprisingly versatile layouts.

Would you elaborate a bit on that, please? I see how I can TableID into a field, but I don't see how it can be used for... well, for anything.

Would you elaborate a bit on that, please? I see how I can TableID into a field, but I don't see how it can be used for... well, for anything.

See attached.

Multitable.zip

Thanks. We had a little misunderstanding here: you see, TableID is a Filemaker term (see Design functions > TableIDs function). For a moment there I thought you have found a way to dynamically control the TableID of a portal - thus changing the actual table being viewed (as the original question requested).

Unless I am missing something, you're showing as portal filtering based on record type? I do not intend to belittle (it's the most elaborate portal filter one could imagine), just to clarify.

Yes you had me going there for a minute too (as the original questioner).

Thanks to all for the info from all - I can see the simple answer to my original question is a resounding 'no'. But there are some other places to go - as the various files suggest. That last one (from BruceR) sure is elaborate! - I'm still figuring. But they've given me plenty food for thought.

thanks

To Soren Dyhr - thanks for the file. Nice idea. But it appears that your solution will only work if the filed lables are the same (in my case the field labels are very different) - or am I missing something?

Yes, as I mentioned it is a non-standard technique, one "real" data table holds many table definitions. The same technique can be extended for field definitions also, allowing you to have fields of different name and type associated with each defined table. You can also establish interesting on the fly data relationships as well.

But it appears that your solution will only work if the filed lables are the same (in my case the field labels are very different) - or am I missing something?

They do not need to be the same just change the GetField( calculation to to pull different ...I had "name" outside the paranthesis to demonstrate how flexible it actually is to make an indirect call. But meanwhile have I thought further of the merge I initially suggested and you might be better off with a structure like this:

http://previews.filemakermagazine.com/videos/513/DataTagging_full.mov

--sd