Custom LOV Creation and Filtering Configuration

You should select the ‘LOV Custom’ parameter type . This type is specifically used to create an ad hoc LOV based on an SQL statement solely for the validation of the current report parameter . Once selected, you double-click the ‘LOV Query’ field to enter the required SQL statement . This ensures that any modification to this LOV will not impact other reports, unlike shared LOVs of type ‘LOV’ .

The LOV SQL must include the columns `value` and `description` . It may optionally start with an `id` column . If an `id` column is included in the select clause, the value from this column is used as the parameter’s bind value for the main report execution . If the `id` column is excluded, the value from the `value` column is used for binding the parameter restriction .

To mitigate performance issues with large LOVs, you should check the ‘Filter Before Display’ setting . By default, this setting is unchecked, and Blitz Report queries all possible parameter values in the background upon selecting the report . Checking ‘Filter Before Display’ forces the user to enter a (partial) value before the LOV is displayed, thereby restricting the dataset queried by the form, which significantly improves the initial load time .

Both are used for parameter validation . However, the key limitation of ‘LOV Oracle’ is that you cannot directly edit the underlying LOV query from the Blitz Report form, as the value set must be maintained via the standard Oracle Forms interface . Conversely, ‘LOV Custom’ allows immediate, ad hoc SQL modification directly within the Blitz Report interface .

Yes, if you decide that your custom LOV query would be useful for other report parameters, you can easily promote it to a shared LOV . To do this, click on the ‘Save as shared LOV’ button within the LOV definition window .