This is a follow up article to document new material from my recent FM-DiSC presentation: Virtual List on Steroids. The presentation was intended for developers who are (at least) somewhat familiar with virtual list, but for those not actively using virtual list, I decided to begin with a demonstration of “the problem” (or one of the problems at any rate) that virtual list was invented to solve.
Welcome back for the second installment in our exploration of Virtual List Reporting (a.k.a. VLR). Demo file: VLR-part-2.zip
To avoid repetition, this article will assume the reader is familiar with concepts and techniques introduced in part 1 (some of what follows may appear to be gibberish if the reader is not)… but to briefly recap, here are some benefits of VLR:
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.
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.
Today we’re going to look at a technique called Magic Key, which allows you to flexibly create and populate related records. I believe that the name originates with European developer Ugo Di Luca, and we’ll get to the details in a moment, but first let’s look at a scenario where it might come in handy. Have you ever built or inherited a system with data stored in text fields formatted as check box sets?
There are pros and cons to this approach, and one of the cons is that data stored in this manner can be a pain to report on. But I have good news: Magic Key can help alleviate that pain Continue reading →
One of the useful things you can do with a FileMaker summary report is reorder it based on the contents of a summary field. Since this is a bit abstract, especially if you’ve never done it before, let’s look at a concrete example.
Yesterday we looked at a simple method to flag unique entries in a found set. This time, we’re going to look at an additional use for this technique, using the same data set and demo file as last time.
As you may recall, we have a simple table of sales data, and previously we produced a summary report sorted by salesperson, but reordered by total sales, so that the top performing salespeople appeared at the top of the report.
A question that comes up regularly on various FileMaker forums is some variation on “I have a table of sales data for my organization. For a given found set within that table, it’s easy to produce a report grouped by salesperson showing number of sales, total sales amount, etc…
…and at the bottom of the report, I can easily display grand totals for number of sales and total sales amount…