Resetting the parameters in the Headstart Report Launch Form – small but useful change

I would not be offended if you were to decide to quickly skip this article. It ain’t much. However, for my current project it proved pretty important, this apparent triviality. We have a modern-tradition technology-stack: Designer 10g, WebForms 10g, 10g RDBMS and AppServer, Headstart and CDM RuleFrame supported by CVS, Jira, Repository Object Browser etc. We have a substantial number of reports that will be used on a frequent basis by our users. The Reports are handcrafted. They are all launched from the Headstart supplied Report Launch Form, qms0012f.

All reports are set up in the QMS_MODULES table. The parameters associated with each Report are defined in the QMS_MDE_PARAMS table. The generic Reports Launch Form reads the parameters for the requested module and presents them to the end user like this:

The user can provide values, sometimes by typing in the Description item, sometimes by selecting a value from a List of Values, based on a query that is stored as part of the Parameter definition. Then the report can be run, after which different values for the parameters can be set.

However, we ran into the issue that the Description “values ” for the parameters can be set to another value, but they cannot be RESET, set to NULL.
When you clear the field, you would expect the report to be run without a value for that particular parameter. Unfortunately, that is not the case. The qms0012f report launch form uses a hidden item that contains the real value – not the display value – for the parameter. Changes in the displayed value are supposedly copied to the interval value used when the report is launched, but this logic is flawed in cases where the display value is cleared.

Analysis and Solution

The flawed logic is found in the qms0012l library that is attached to qms0012f. To be more specific, de QMS$PARAM package contains a procedure check_par_value. This procedure is responsible for copying the value from the display field to the hidden value field. The logic is described as follows:

— 6.5.3.2 Populate parameter value with description
—         only when :
—         1. default_value_displayed differs from value_displayed;
—            if default_description is null, validate against default_value
—         2. item is updateable: if LOV query is not suitable for population,
—            update_allowed has been set back to false
—           3. item is not a multiselect item

The implementation is this piece of code:

      if -- 1.
      	 nvl( name_in(qms0012f.get_param_description_item(p_block_name))
      	    , '#$%^&*'
      	    )
      	 <>
      	 nvl( name_in(p_block_name||'.default_description')
      	    , nvl( name_in(p_block_name||'.default_value')
      	         , '#$%^&*'
      	         )
      	    )
      	 and
      	 -- 2.
      	 get_item_instance_property
      	 ( qms0012f.get_param_description_item(p_block_name)
         , current_record
         , update_allowed
         ) = 'TRUE'
         and
         -- 3.   (added in 6.5.3.3)
         upper(name_in(p_block_name||'.lov_multi_select')) = 'N'
      then
         populate_val_with_desc(p_block_name);
      end if;

The problem is in the first condition: when the ‘value’ in the displayed item is NULL or missing I should probably say AND the parameter does not have a default value – which is quite common for parameters that depend on other parameters – then the value is NOT copied to the value field. I believe that this is wrong and the value SHOULD be copied in that case. So I propose the smallest code change: add a single character to the string ‘#$%^&*’ on the left hand side of the first condition – any character will do. My objective is to ensure that if the display field is cleared and there is no default value to set, that then the internal value field is synchronized with the displayed field. Otherwise the end-user will be confused at first and annoyed later on.