Next, we will create the C/AL code to calculate a Fan's age (in years) based on his/her Birth Date and the current WORKDATE. The logic is simple: subtract the Birth Date from the WORKDATE. This gives a number of days. So we divide by 365 (not worrying about Leap Years) and round down to integer years (if someone is 25 years, 10 months and 2 days, we will just consider them 25). In the following code, we did the division as though the result were a decimal field. But because our math is integer, we could have used the simpler expression:

FanAge := ((WORKDATE - "Birth Date") DIV 365);

Finally, we'll write the code to check each Fan record data against our selection criteria, determining if we want to include that fan in our output data (SelectThisFan set to True). This code will select each fans who fits any of the checked criteria; there is no combination logic here. Following is our commented C/AL code for Report 50002:

After this version of the report is successfully tested, enhance it. Make the report support choosing any of the options (as it is now) or, at user option, choose a combination of age range plus gender. Hint: add additional checkboxes to allow the user to control which set of logic will be applied. We should also change the code to use the CASE statements (rather than IF statements). CASE statements often provide an easier to understand view of the logic.

Test the completed report

After we Save and Compile our report, we'll Run it again. Now we get an expanded Request Option Page. After we've check-marked a couple of the selection criteria.

Now Preview our report. Using the sample data previously illustrated, our report output shows two records, one selected on the basis of Gender and the other on Age.

Output to Excel

An easy way to get the data to a mailing list is now to output it to Excel, where we can easily manipulate it into a variety of formats without further programming.

Here's what that output looks like in Excel:

At this point we have a report that runs and is useful. It can be enhanced to support more complex selection criteria. As usual, there are a number of different ways to accomplish essentially the same result. Some of those paths would be significantly different for the developer, but nearly invisible to the user. Some might not even matter to the next developer who has to work on this report. What is important at this point is that the result works reliably, provides the desired output, operates with reasonable speed, and does not cost too much to create or maintain. If all these goals are met, most of the other differences are usually not very important.