Sounds like you don't have the right relationship linking your incoming calls table (the basis for your portal as I read this) and your customers table. If you did, you could add fields from your customers table directly to the rows of your portal.
It would help to describe your tables and relationships in more detail. A screen shot of your relationships graph might be helpful, but if you do, please also describe which box on the relationship graph is the basis for your layout and which the basis for your portal.
Yes, the relationships graph is very complex**. The relationship is between the customer phone number and the incoming caller number. Should I have this relationship made in the Caller ID database, the Customers database, or the general one where the portal is being displayed?
** The client I am developing for has a system in place with multiple files, so that is why there are multiple relationship setups.
Without the information that I asked for, I can only provide a hypothetical example.
If you have these relationships:
IncomingPhoneCallsTO::PhoneNumber = CustomerTO::PhoneNumber
Then you can place a portal to IncomingPhoneCallsTO on a layout that specifies LayoutTableOccurrence in "show records from" and include any fields that you need from CustomerTO in the row of that portal.
You might need to consider the fact that phone numbers are not as unique as you might think. Customers abandon phone numbers and then a new customer acquires it--resulting in two records in the Customer Table that match to the same phone number as it is very unlikely that the first customer will tell you when they abandon a phone number.
In layout setup, which table occurrence is specified for the layout in "Show Records From"?
In portal setup, which table occurrence is specified in "show related records from"?
Global or Global 3?
CallerID or CallerID 3?
If you are using a portal to CallerID 3, on a layout that specifies Global 3, then NO records of any kind will show in that portal as you do not have any relationship shown linking these two table occurrences.
If your are using Global and CalleriD, then we have to go back and look at your actual relationship graph and pick out those particular table occurrences.
I did not know they were separate. This makes sense. I'll make the appropriate changes and let you know.
You'll also need to make sure that cCustomer_Phone is a stored, indexed field. I don't know for sure what kind of field it is, but that lower case c is often a naming convention for a field of type calculation. That will work here, but only if it is a stored calculation.
I recieved the alert that no more than one relationship can exist between two tables on the graph. It asked if I would like to create CUSTOMER 2. My GLOBAL table is connected to Customers already, but I don't know how to throw the CallerID in there. I can't change the layout reference of plain 'GLOBAL' or it will mess things up.
I need to see how it's actually connected in relationships now.
So your layout is really Global here?
I asked about that several posts ago...
And what is the exact name found in "Show Related Records From" in portal set up for the portal?
Yes, the layout is GLOBAL. Not GLOBAL 1 or 2 or 3.. And the portal displays CallerID. Not CallerID 1 or 2 or 3.
BUT, the graph won't allow me to create the relationships I need between GLOBAL, CallerID, and Customers because there are already other relationships going on. That is why I figured I'd make different variations of these.
If you can't base the layout on a new occurrence of Global, keep it based on Global and link in new occurrences of Customer and Caller ID.
Refer to my earlier "Hypothetical" example and use Global where I use LayoutTableOccurrence.