3 Replies Latest reply on Feb 22, 2014 10:25 AM by Stephen Huston

    Best Practices or thoughts about Selecting Reporting parameters

    pmconaway

      Ok, I'm working on a solution where the end user will select options that they want to report on. It is a standard report but the end user selects which records to report on. i.e. builds the parameters of a find request. My question for Technet is: What are your thoughts on how to go about this? What have you done in this sort of situation?

       

      I'm more looking for ideas that others have made work.

       

      Here is what I'm thinking so far. Create a layout that has the report filtering fields on it and a submit button on it. The submit button would then perform a find and take the user to the Report layout. Personally this seems like a kludgy way to make this happen. I'm looking for new way to make this happen and I having a problem getting out of old design ruts.

       

      Paul

        • 1. Re: Best Practices or thoughts about Selecting Reporting parameters
          Stephen Huston

          This sounds like an awkward goal if it's really meant to be open-ended reporting.

           

          I suspect that one needs to build the reports, including appropriate layouts and scripts, but leave some of the options open to user selection, such as date range, etc.

           

          I did this with a large system that had reports growing almost weekly, finding it difficult to provide reporting buttons. My solution to the reporting screen real estate issue was to create value lists of report names by department, and give each department a popup menu from which to pick the report they wanted to run. The field had an onModify script trigger which then ran the appropriate script for the chosen report, complete with any dialogs or utility screens for entering parameters such as date ranges.

          1 of 1 people found this helpful
          • 2. Re: Best Practices or thoughts about Selecting Reporting parameters
            pmconaway

            Stephen, thanks for the response. It was exactly the type of response i was looking for. I am looking for ideas for a better interface to the reports. i.e. the user getting to the report with as few actions as possible. In your example selection from the dropdown and press the tab key.

             

            I hope you may have some insight on this question. Is there any easy way to get prompts (report variables) into a global or local variable without creating more database fields? I started looking at custom dialog boxes and it can display up to 3 fields from a database table, but I can't link those to a variable directly. I'm very familiar with setting variables in script steps as I'm an old programmer (COBOL). I am just trying to avoid adding database fields that will only be used for temparary choices.

             

            Paul

            • 3. Re: Best Practices or thoughts about Selecting Reporting parameters
              Stephen Huston

              In my example, you don't need the tab key on the popup-menu of reports. Using the onObjectModify trigger launches the scrpt as soon as you choose an entry from the list. I have the value of the popup field set to "Choose Report..." by default, and reset it to that value at the end of the reporting script.

               

              As for variables: In each of my FMP files, I have a table for globals which contains no data from the regular tables, just things I want to use in the system. Among the fields in that utility/global table are 3 text fields, 3 date fields, and 3 number fields. This covers everything I am likely to need for the Show Custom Dialog script interactions, and these can be used for collecting variables before or after the appropriate script step is triggered.

               

              My script trigger field (with popup menu) is another global text field which makes it available for use anywhere in the system from that globals table.

               

              This allows me to leave all of the reporting choice fields separate from any regular data table, but they remain accessible to use anywhere in the system, even in a multi-file system. (When using data separation model files, I put all of these globals in the interface file.)