Today we’re going to look at a reporting challenge that comes up from time to time, and a technique that can be useful to have in your developer bag of tricks.
In the demo file, Non-Breaking-Groups, we have a simple personnel file containing employees spread across all 50 U.S. states, with between two and nine employees per state.
We have a requirement to produce a report showing personnel grouped by state, like so:
Last time we looked at several summary reporting tricks, including a conditional subsummary (when an item’s Status is “Scheduled” it will have a value in the Substatus field — otherwise Substatus will be blank). The challenge was to generate a summary report showing Substatus only where appropriate, without seeing any annoying empty gray rows beneath Pending, Cancelled or Completed. And last week’s report worked fine… in preview mode.
Continue reading “Conditional Subsummary Report in Browse Mode”
One of the best ways to learn about a particular FileMaker feature or behavior is to build a demo. You might build one in response to a client request, or to try to answer a question somone has asked, or just to see what happens. At any rate, today we’re going to look at three demos, each of which explores some aspect of summary reporting. For reasons of backward compatibility today’s demos are in .fp7 format, but you can convert them to .fmp12 format if you are so inclined.
What these three demos have in common is multiple sub-summary parts on reporting layouts… so what you see on the report depends on how you sort it.
Editor’s note: Today I’m pleased to present a guest article by Michael Rocharde, author of FileMaker & Me, an interactive multimedia book focusing on FileMaker Interface Design.
FileMaker has always been an incredible tool for generating reports and for many years, I used to have a report screen with banks of buttons to generate all of the individual reports. In the last few years however, I’ve added a global field, to the footer of each module data entry screen, with a pop-up menu, listing all of the different report options for the module in question. To that global field, I’ve added an onObjectModify script trigger which sets the name of the report as the parameter that generates the report they want. Simple, very effective and it has the added advantage of giving the user all the reports that are relevant to where they are at the time.
Recently I had a project where some of the reports that were required were restricted to the different privilege sets and I was looking for a quick (and easy) way to accomplish this. I started thinking about whether I could use a related value list to solve the problem and came up with, what I think is, an elegant and very simple solution.
The first thing I did was create a Reports table with just two fields, Group (for the privilege set) and Report (for the name of the report itself).
