This chapter contains the following topics:
With the saved query control, you provide users with the means to persist query criteria for use against the business view (BV) of the form. The control provides flexibility in the query filters and logic. You can constrain users to choosing a query from a preset list, enable them to input and save query parameters themselves, or give them any other combination of access.
The saved query control is a regular form control and can be added to a form as such, either from the Insert menu or tool bar. Because you must query on a BV, do not place a saved query control on a form type that does not permit BVs (that is, message forms) or on forms where the BV fetch is disabled. All filtering occurs on the BV columns that you select. A single BV column may be used as a filter more than once on the same form. You can display the query results in a grid or parent child control.
The query control appears by default with two parts: a titled drop-down field and two links (Save Query and Edit Queries). With the control properties, you can opt to display the links to the left of the combo box or beneath it. You can also choose to hide the links. Saved queries reside in the system as user overrides. You can use Cross-Reference and Object Management Workbench (OMW) to find and manipulate them as such. Because they are user overrides, saved queries are translatable.
In brief, these are the steps you perform to implement a saved query control:
Start with a form that has one or more BVs attached to it.
Place the saved query control on the form and configure it.
Place control on the form intended to display query results (that is, a grid or a parent/child control).
If you want a BV column to act as a filter, add an edit control for it and then configure it to be filterable by choosing a comparison operator to use.
If you want to enable users to select their own comparison type, add an edit control for each one and configure it with the Runtime Select comparison type.
If you want to provide users with a defined list of queries, run the application and make and save the queries (which are saved as user overrides).
Then, find and copy the user overrides into the *PUBLIC list.
This table identifies design-time property values you can set that can impact the saved query control significantly:
The saved query control is initialized as part of the form initialization process. To initialize the control, runtime checks the user override table for all saved query records that match the current application/form/version combination, user ID, current role or roles (*ALL), and *PUBLIC. If any records are found, runtime populates the drop-down field with the saved query names in alphabetical order.
In some cases, runtime might find duplicate query records between roles. For example, if a single user's query was copied so that it could be accessed by *PUBLIC, then runtime would discover that the query criteria are identical. In this case, runtime returns only the proprietary record (the user's query rather than the *PUBLIC version of the query). In all other instances, runtime returns one of the saved queries without preference as to which one it returns. Notice in this example that the entire saved query record was a duplicate. The saved query control enables duplicate saved query names; runtime can distinguish between queries with the same name with different criteria (non-duplicates) and queries with the same name with identical criteria (duplicates).
After initialization, runtime interacts with the saved query control only when the user works with queries. If the user selects a query from the drop-down list, runtime first clears all of the fields that have been flagged with the property value, Allow in Saved Query (including hidden columns and filter fields). Then runtime populates the fields as dictated by the saved query. Special values that require calculation such as user ID, today's date, and so forth, are calculated at the time that they are applied into the field. The act of populating the fields does not instigate a fetch; instead, the user must click Find to instruct the engine to fetch data based on the retrieved saved query.
When a user creates or modifies a saved query, runtime does not write those records to the user override table until form close. On the other hand, when a user deletes a saved query, runtime purges that record from the table immediately.