Well in your books table, I would've put an attribute (field) for book type, made it a dropdown list. Then a report layout without a body part would show book type and total number (using a sub-summary part, a summary calc, and a summary field)
You could also have a layout with the body part to serve as an index, with a dropdown that would sort either alphabetically, by author, or by book type.
There may be a reason for 42 different TO, but I can't think of one.
Could you explain a little more what you mean by having the body part serve as an index. How do I do that? And also I have other stuff being displayed on that layout. Will having the body part serve as an index allow me to still display the other stuff?
Maurice said: "The problem is I have 42 different types and I had to create 42 different TO to filter the different types. I'm getting all the right results so that structure works ok. But the relationships graph looks terrible. Is there a better way to do this that would avoid the need for so many TO?"
You could use a single TO.
On the Ui side use a global text field to act as the selector /key field.
On the BookType side land the relationship on your bookType field.
In value lists create a value list of book types.
In the Ui insert the Global field informed by the BookType value list formatted as a drop menu.
Add a portal for BookTypes.
If you want to learn more about writing more efficient FileMaker Solutions there are extensive resources accessible from the documents page "Writing about developing" of http://www.deskspace.com.
OK, I've now moved to the FM Community, and am in a position to say thanks to you all, especially to Steve and Phil for providing the links to the sample file and the tutorial.