Hi,

The requirement is to print a report that details the parent and all
related child records for mutiple child tables

A parent table (patients) has multiple child line item tables (
patientdoctors, patientnurses, patientlocations...) and the number of
line item records per child table can vary per parent record.

Several approaches, each presents issues.


1. mulitiple sub summaries I can not get to work
should this approach work?

2. parsing the respective line data into a variable presents too many
issues with output column alignment; is tedious but plausible


3. printing a pdf using append, with a different layout/TOC for each
child table works, but the pages do not 'roll up' ; the content should
flow on, as it is I get a new page for each append. THis would probably
be the most flexible and preferred approach, if not for the new page
aspect.Am I missing something trivial here?



the output should be structured:

patient
names, dob, age ...

patdr
A drname
B drname
C drname
....

patlocn ward bed
1 q
2 r
3 s
4 t
5 u
6 v
....


patnrs
1 nrsname
2 nrsname
3 nrsname
4 nrsname
5 nrsname
....

Hi,
Surely others will propose you more elegant solutions, but the way I would
handle that would be to create a new table, that would be filled up by the
various 'child' tables. Then the solution becomes trivial as you have only
the master table and the 'superchild' table to show up.
Remi-Noel


"105" <cortical (AT) internode (DOT) on.net> a écrit dans le message de
news:00cab2b9$0$15611$c3e8da3 (AT) news (DOT) astraweb.com...

On 4/01/10 3:45 PM, Remi-Noel Menegaux wrote:
apparently not :-)



but the way I

Yes, a utility construct i guess it will have to be. A bit galling to
have to duplicate data (even id/type) just for a report. Yet another
limitation of FileMaker it seems.

thanks Remi

On 6/01/10 9:03 AM, 105 wrote:

this turned out to be a more involved process than one may think.
a new set of rels/TOG, a related field set for each rel, superimposed
on each other once the appropriate field widths established, and
conditional calculation for the relavant field labels and back and forth
playing with the spacing ...

In the end it turned out to be a whole lot cleaner to just use multiple
portals with sliding; which all worked quite well.

Ever since time began (FM time that is), I know it has been dogma not to
use portals for reports; and I never have. But it seems to work for me here.

The portals are set to a row count that should be greater than any line
item counts ever encountered. Easy enough to add a trap for exceptions,
and calc text into a global, add a flag warning ...

Another option is to create a few calculation fields that concatenates
the related records into one or two fields in the parent table. For
instance, based on the structure you outlined in your initial post,
you would create a calculation in the PatDr table -- let's just call
it "Display" -- that concatenates the two fields you have listed < f1
& "[tab]" & DrName >, where the angle brackets are just showing what
the calculation is and the [tab] is a tab pasted from a word program.
Then do the same for the other tables -- < Ward & "[tab]" & Bed > ; <
f1 & "[tab]" & NrsName >.

In the parent table, you can then create a calculation and the List
function to grab this data, maybe something like: "Patient's Doctors:
[p]" & List ( PatDr:isplay ) & "[p][p]Patient's Location:[p]" & List
( PatLocn:isplay ) & "[p][p]Patient's Nurses:[p]" & List
( PatNrs ). With text formatting functions you can make this field
look however you want and it will always return exactly the right
number of rows (though you may need to use conditional statements here
and there to check for empty fields or relationships).

This setup doesn't require any additional tables or relationships --
just a couple extra fields. On the layout, set the tab break the
appropriate distance to account for variations, or, if you'd rather
have the data clipped than bumping the columns out of alignment when
names are long, skip the calculation fields in the related tables and
use a pair of calculations in the parent table for your left and right
fields. Again, this means using conditionals to deal with empty
values, but it's not a big deal.

Hope this helps a little.

Best,
-J.

On 10/01/10 2:30 PM, jahn wrote:

Thanks Jahn, I was hoping to avoid calcs, but it is an appropriate
option. I had resorted to just adding portals, with sliding. Works
surprisingly well.

Historically, portals had always been a no go, something one
automatically ruled out as an option. But I see no issues at the moment.

I come again into this thread, picking up the wish to avoid calcs.
Back on FMP6, with very complex set of calculations - often piled up as one
master calc field referring to child fields - I sometimes saw unacceptable
model refreshing times - sometimes as much as 10 seconds -, so I replaced
them by scripts with globals, and I got a 10 to 1 better response time (in
favor of the scripts). But the price to pay was to add on the layout two
buttons. One called 'Update THIS record' and the other 'Udate ALL records'.
My client then was pretty pleased, as he got acceptable response times while
obliged to hit the button(s) after each set of changes to the data.
I don't know if this technique had become obsolete with the new FM versions.
My guess is that for reports - which just happen once on a while, and that
user launches with scripts - the above technique could be an option.
Just my two cents.
Remi-Noel

On 12/01/10 3:26 PM, Remi-Noel Menegaux wrote:
Hi Remi-Noel

for this sort of calc, where the calc field is targeting fields in the
same table, it could easily be an auto-enter calc with replace, so no
ongoing calc engine overhead like in the 'old days'.

My preference to avoid calcs, was really about the requirement of an
additional field to each table, when a report should be able to process
the existing data.

2 reasons really. One is avoiding having to make changes to the data
file, which means a client site visit. Second is a more general move
away from the whole calc based FM design approach, to a more primary
data only design. If it can't be rolled up to a SQL implement, I don't
want it there (kinda). Not an absolute, just has become a general
approach /exploration process.

Anyway, as I found, using portals with sliding, seems to work quite well.