Yes it's possible. But much depends on the tables and relationships behind your layout and those portals. One option would be to set up your portals so that they all reference the same data source table via different relationships and portal filtering.
You don't describe all 7 portals so we can only guess as to the purpose and function of the other 4 portals....
Why do you want to combine such dissimilar information into the same table so that they list in the same portal?
Thanks for your reply
I'll start by simplifying what i am trying to do. I will start by regrouping two: EX:
My main table is "Projects" with an Project ID number (Proj-23) to link the tables.
My first related table is "Project data"and I have a portal, using Proj-23 as a relationship, I have:
-Photocopy (with price etc...)
-business cards (with price etc...)
-Graphinc work (with price etc...)
Nest related table is "Notes", using Proj-23 as a relationship and I have different things in there wich are not set product.
-Gallong of paint (with price etc...)
-calling in the states (with price etc...)
I would like to see them on 5 different lines on my "Billing" portal which is also link up with Proj-23 on the same main layout.
Sorry, if i am not good at explaining.
It does not answer one of my original questions:
Why do you want them all in the same portal?
What problem does that solve for you?
As I stated before, your two portals could be to two different occurrences of the same table that use different relationships to show only "line items" in one portal and only "notes" in the other. A third relationship to a third occurrence of that table would then show both line items and notes.
A "table occurrence" is what we call a box on the relationships graph. You can create multiple boxes (table occurrences) that represent the same table in order to set up different relationships to the same table on the other side of the relationship.
Invoices::__pkInvoiceID = LineItems::_fkInvoiceID AND
Invoices::constLineItem = LineItems::Type
Invoices::__pkInvoiceID = Notes::_fkInvoiceID AND
Invoices::constNotes = Notes::Type
Notes and Type would be two occurrences of the same table. The "const" fields would be calculation fields that identify the Type of record. A third relationship:
Invoices::__pkInvoiceID = InvoiceDetails::_fkINvoiceID
where InvoiceDetails is yet another occurrence of the same table as lineItems and Notes would then be the basis of a relationship that show both notes and LineItems in the same portal.
But whether that is a good idea or even necessary remains to be seen.