I don't know if I'm stratching portals' abilities here, but here's what I want to do:

I have a large all-inclusive file "Employees" with all company's employees and their attributes. There are many companies, each with one or more employees. Employee's id is always a concatination of company# & employee#.

I also have a smaller file "Temps" with a subset of those from "Employees", and without all the attributes. Employee's id is same as in above.

I want to view a portal in "Temps" that'll only have local temp employees, and their attributes from "Employees" file

1. If I create portal based on company#->company# relationship, it'll give me ALL employees from "Employees" that work in this company. I only want those from the local "Temp" subset.

2. If I create portal based on employee id->employee id relationship, it will show me only one employee per record, so what's the point of the portal, right?

3. I was thinking of creating a new employee id based only on company# for only those employees THAT ARE IN BOTH FILES. That'll give me what I want now, but when the list grows in the future, someone will have to manually enter same id for employees in both companies. So I'm at a loss as to wheather it could be done.

Thanks for your thoughts

Ok, so here's an answer for you.

1. Create unstored calculation fields in the temp file to bring in relevant data elements that you require from the main file, based on a match on employee number.

2. Create a self-join on company number in the Temp file, and base your portal on that. In the portal, include whatever fields are required from the main file (via the unstored 'mirror' calculations in the temp file).

There are a few other ways to go, but based on what you have said, the above is perhaps the most 'painless'.

Ray, you're a ray in the dark bro. I was getting dipressed, 'cause I tried to create a relationship based on Case(IsValid(blah blah)) in the main file and connect it to company# in temp file. But FileMaker can't index calc fields, and it wasn't working.

Your solution deserves a brew.

Thanks a lot!