Is there any way to make data from a many-to-one relationship appear in a repeating field instead of a portal?

I want to use the getrepetition function and it doesn't work on portal info (as far as I can tell at least)....

Yes, but the related field has to be indexable and the 'repetition' referred to is according to the natural creation order of the related records, not necessarily that of the portal or the relationship itself, if they happen to be sorted otherwise. You use a value list based on the related field to grab the data, but you need to have a serial field in the child table so that you can sort the value list by this field and preserve any duplicates. If you do not sort the value list by the serial field, the results will be returned in alphabetical order.

See attached for a quickly-created example.

RelatedToRepeating.zip

Is there any way to make data from a many-to-one relationship appear in a repeating field instead of a portal?

If this is for printing purposes, which indeed can be dodgy with scrollbars on the portal ...must you know that with 7.0 can portal be cut up in chunks...

http://www.newcenturydata.com/downloads/horiz_portal.zip

But do also consider the change into bidirectionaly of relations, that makes you "see" values a table away - which means prints can be made in a lineItems tables layout pulling the parent records values to the header of list layout.

--sd

Queue. In your sample file, what if you wanted to put a condition on which fields you pulled into the repeating field. Say you added a boy/girl field for the children and you only wanted the boys to be pulled into repeating field. Where would that condition fit into the calculation?

That's exactly why you should NOT be using repeats. Using related item records, you can find just the records you are looking for. Do the report in the line item table.

To answer the question, you would use a calculation field in the related table that returns a value only when the child is a male. Case( sex = "m"; Name ), for example.

Then, base your value list on this field instead of the regular one.

The question begs to be asked, though, what purpose this serves in your solution.

I've got a membership database. And I want to be able to track all members' payments in a table for payments. There's a one to many relationship with members and payments. Each payment will have a different type: Dues, Fall Conference, Spring Conference, Other... It will also have a year associated with it. So it'll be Dues for 2004 of the Fall Conference in 2005, etc. My goal was to have a field for each member with every year they had paid their dues, so I want to pull the dues year from the payment field automatically when the record is created in the payment table.

So when I saw this thread, it seemed like a way I might be able to do that.

Am I totally crazy for trying to do it this way?

Am I totally crazy for trying to do it this way?

No failures, counts as important expirience as well ...but you might learn a thing or two by working your way thru this thread:

http://www.fmforums.com/threads/showflat...true#Post163265

--sd