My project involves printing a report on each transaction, including relevant feedback text from the two most recent *related* transactions. I have been using a portal with two rows to accomplish this. The only problem is that the related field's text entries vary tremendously in length. To accommodate the longest, the portal row is a pretty tall brick, but that means that lots of space is wasted on the portal rows with barely any text. I really dislike big white space and wasted page-breaks. As far as I can tell, no sliding/printing options can get a portal row to shrink its height. Right? (If it were possible, I might even go for more than two rows, since on average about four recent transactions would fit on a page.)

Of course, if I had only *one* recent transaction for each record, I could slap the related field directly onto the layout (since it will automatically return the most recent record from a relation sorted by descending date) and apply sliding/printing options to it so as not to waste vertical space.

I have searched in vain for a calculation that would allow me to create fields in the parent db that tap the *second* related record, so as to be able to work the related fields with sliding/printing. Something like "GetRepetition(field,number)" except it would be "GetRelatedField(relation,number,field)". Nothing like that exists, right?

Any thoughts or workarounds?

ESpringer

create a 2nd relationship that will show up the second field as the first record. or easier,

script a goto second related record and append it to the first field for your print out. The script can be called from you print script routine.

Charles

Charles,

I really like the idea of using a second relationship in which what was the penultimate record comes to the top in sort order, but I'm not sure how I can specify a new relationship that will always take the *second-in-line* in the old relation's sort order... I had assumed that wouldn't be possible (?!) or wouldn't be easy. I'd prefer not to run around with scripts tagging items, but maybe that's what it would take? Nah, what I'll try is making a variant relation with a RH self-join key that duplicates that original self-join RH key value except where there's no more recent feedback record... hm.

As far as appending text to the first field -- I didn't specify this, but I do present other info from the record besides the text. If I were to do it as calculated fields, I'd want to make multiple fields for each related record, including clear formatting with date and other statistics on the each feedback item separately (exactly what portal rows are good for!)

(So,... gripe gripe -- Is there a reason FileMaker couldn't make resizing portal rows at print time work just like resizing fields at print time? I suppose that belongs on the FM features request page...)

Thanks...

ESpringer

Why don't you print from the related file?

BobWeaver said:

Why don't you print from the related file?

Well, this is a self-join -- I am in the related file -- but your point still holds...

What I'm printing for the current transaction is a different set of fields, and these still need to be at the top. But I suppose I could find the records for which I want to recap the feedback and put them in list view, then create a header with related fields from the most recent record for this individual...

For some reason, I've been squeamish about doing real relational work in headers -- something hasn't worked cleanly in the past -- but (checking...) I think that was portals, because related fields, just slapped in there, behave OK.

Thanks for the nudge!

-ESpringer

I'got some maybe good news. I found out by accident that, in FMP V6, portals can SHRINK!!! It's great.

Why this is not listed in the new fatures I do not know.

Paul, are you sure the row shrinks and not just the number of rows. The number of rows has always been able to shrink, but not the row itself. Hmm, I must go check.

ESpringer, I understand situation now, but I've never encountered any problems printing related info in the header. I have occasionally had to print portals on some reports where I was using a multi-key relationship. Luckily everything fit on one line.