In one of my databases I have a portal. Eleven records fit nicely into
my layout; however some clients have twelve or more.

No matter how I try to print them, FM7/Windows 2K will only print the
first eleven. I've tried displaying the records I want printed or
enlarging the portal, but it's the same problem - as soon as I get more
than eleven records, I get two pages - both showing the first eleven
records in my portal.

I can work around it - print one page, disassociate the first eleven
records, print the page again, relookup in original database
(thankfully, I *have* that option) but, well, it's inelegant and
timeconsuming and should not be necessary in a relational database.

Any ideas how I might tell Filemaker to print records 12-x in a portal,
and only them?

In article <1126702445.067386.176330 (AT) g43g2000cwa (DOT) googlegroups.com>,
"Catja" <Valendon (AT) gmail (DOT) com> wrote:

You can print a multi-page layout with a large portal, by expanding the
layout body and then making the portal show more rows. However, a portal
row at the page break may not print properly. Portals are not well
suited to printing in a multi-page layout.

You are really better off to design a layout in the related table
occurrence, as a columnar list/report, and put the fields you want in
that layout.

For the sake of this description, call the two tables (or table
occurrences) Table A and Table B. Table A is the "master" table in your
current setup. Table B has the records that show up in the portal of
your current layout. You want to be able to print all the records in
Table B that are related to a particular record in Table A.

In the context of Table B, create a new layout that is a columnar
list/report. Put the Table B fields you want, in the arrangement you
want, in the body part of the layout. In the header of the layout, put
the fields you want from Table A. Expand the header as needed. We will
call this layout "B Report" (you give it a name that makes sense to you)

In the Table A layout that contains the portal to Table B, put a
pushbutton to Go To Related Records in Table B, in the B Report layout,
and select "Show Only Related Records." Label the pushbutton
appropriately.

In the Browse mode in the Table A layout, click the pushbutton. That
will take you to the B Report layout, with only the records related to
the current record in Table A showing. You can sort the records as
desired. In fact, if the sort is defined in the relationship definition,
they should already be sorted. Then you can print. All the Table B
records that are related to the Table A record will print, and the Table
A fields in the header will print.

You may want to put a navigation pushbutton on the layout B Report to
take you to the related record in Table A. You can cause the pushbutton
not to appear in print by means of the Sliding/Printing setup in the
Format menu.

To go a step further, you can design a script that will take you from a
record in Table A to the related Table B records in the B Report layout,
set the print setup and print commands to appropriate settings, print
the report and return to Table A original layout, all with the click of
a single button.


Bill C

--
For email, remove invalid.

Bill wrote:

In the setup I'm printing from, that Doth Not Work. Not even that.

My problem is that I really want to print information from both files,
so I'd be using a portal anyway...

<snip nicely detailed explanation>

Ah. That's where it falls down. What I get when I use my 'go to related
records' script the previous found set in File B. It'll open the
specified layout, so it's clearly doing *something*, but the something
is not 'go to related records/show only related records.

It's not even opening File B in the new window unless I tell it to do
so.
I don't know whether it only works with tables in the same file or what
else is going wrong.

Oh well. Thanks for your help anyway!

Catja

Catja <Valendon (AT) gmail (DOT) com> wrote:

No, if you print from the child file, (or a layout based on a TO of the
child file), it's really easy to put the related Invoice information on
the header without a portal. Just place the related fields directly on
the layout. Try it, it works!

BTW, this process of printing from the child file (or layout based on
child file TO) has been in use since FM3. It's the only way to get a
variable number of invoice line items to print properly. It does work,
trust us.
This is expected behavior. A GTRR (go to related records) does NOT
actually go to a new window, what it does is isolate the found set of
related records. I know it seems counter-intuitive, but you'll get used
to it. I'd write the script like this: (pseudocode)

Go to Related Records (show only box checked)
Open New window, name, size & place it.
Go to Layout based on Child TO
Print
Close Window

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

I am late in the discussion, so I could be completely out of the game,
but a normal 'good practice' is to show to the user portals and to print
on the related file (then with no limit) and come back where the user
were. It can be transparent to the user.
Why couldn't this apply to you ?
Remi-Noel


"Catja Pafort" <usenet (AT) greenknight (DOT) org.uk.invalid> a écrit ...

Catja Pafort <usenet (AT) greenknight (DOT) org.uk.invalid> wrote:

This right here is a clue. As far as I'm aware, FM Server is not
certified for Small Business Server. The fact that it worked well on
your Mac should tell you that there is nothing wrong with your files,
the implementation of the scripting, or FM itself. You did it right.
Taking the same files and hosting them with SBS and suddenly it doesn't
work? What's the operative factor?

Is there any way you can get those files hosted on Win 2000 Server? That
is an absolutely rock-solid hosting platform for FM Server, well proven
and even more stable than Mac hosting.

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

Lynn allen wrote:
I don't know. I just created two new files under windows and tried the
same script step, and this time it worked, but the original files still
don't want to know.

That is unlikely to happen, but I'll keep that in mind for the future.

Catja

Remi-Noel Menegaux wrote:
What I'm trying to print is information from two files - the stock file
(which contains only the current leaflets, plus the quantities for each
month etc etc) and the client file (which contains the full address of
anyone we've ever dealt with. What we print are monthly stock reports -
so client name/ quantities and on the next page, the address. As we're
doing a hundred or so each time, with not enough people in the office,
doing anything other than 'print report, print address' would lead to,
frankly, chaos. Right now I print one page (the stock figures in a
portal), switch layout, print address, go to next record, switch
layout... and it works exceedingly well. Apart from the fact that it
takes long enough.

A solution that switches between the files and sorts records for each
individual report would take a lot longer and be far more cumbersome;
particularly as the current solution is elegant, easy, and is
transparent to the users. (When you provide solutions for a small
company that is very much a consideration. The previous access
'solution' was a nightmare.)

Catja

In article <1126811620.860086.42790 (AT) g44g2000cwa (DOT) googlegroups.com>,
Valendon (AT) gmail (DOT) com says...
As the others have said this should be printed from the child file.

What Remi-Noel and Lynn have said so far apply to printing single
records with variable line items, e.g. an "invoice".

What I think you're asking for is a way of printing multiple parent
records each with variable child records. (E.g. printing a 'batch' of
invoices). Does that sound accurate?

If so...

There are two basic approaches:
1) A looping script that moves through the found set in the parent
record and generates the print jobs one at a time. This works fine, but
it creates 100 1 page print jobs instead of 1 100 page print job. But
there is no reason it can't work. Once you have one record printing
right, its easy to build the looper to print the whole batch.

2) A more slick approach prints the whole batch from the child file all
at once. However, this approach requires a good understanding of how to
build reports with subsummary sections and is one of the harder things
to understand with filemaker.

Essentially you'd create a report with no leading or training grand
summaries. The body would be a very short section with the child record
data, and then you'd wrap it with subsummary sections sorted by the
parent record id, with the trailing subsummary set to page break. You'd
put the document header and footer in these subsummary parts.

Then you find ALL the child items you want to report, sort them by the
parent field, and when you print/print preview the whole thing will
organize into a 100 page document with the child items neatly separated
each onto their own page (spanning multiple pages as need be).

That description doesn't do it justice, but its not as hard as it might
sound.

In article <1h2xbs3.afn49d15agci2N%lynn (AT) NOT-semiotics (DOT) com>, lynn@NOT-
semiotics.com says...
This shouldn't be an issue.

Small Business Server is simply Windows Server 2003 server with some
additional bundled software targeted at small businesses. Its not a
really a whole new operating system edition. Its more marketing than
anything else.

If I read it right I think the files that worked on the desktop were NOT
the same files hosted on the server. So we've really learned very
little.

I don't disagree with Lynn that Windows 2000 is a reliable FM Server
platform. But I do disagree that you should rush off and get one. FM
Server should be fine on Win2003 SBS. If you want to put that concern to
rest though, by all means try it on a 2k server if you have one handy,
or even set up the server on XP Professional or OS X.

Personally I suspect the files, not the server.