Kbase P96608: ADM2: Best practices to change the query of an SDO (filter) when it initializes?
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  25/10/2004 |
|
Status: Unverified
GOAL:
Best practices to change the query of an SDO (filter) when it initializes?
GOAL:
How to apply a global filter to an SDO?
GOAL:
ADM2
FACT(s) (Environment):
Dynamics 2.1A
OpenEdge 10.0B
FIX:
<extract of John Sad's Dynamics Programming Handbook>
Managing Complex Datasets With Extended SmartDataObjects
4.2 Applying global filters to your data
4.2.3 Localizing the behavior in a single object
Preventing your filter from being overridden or lost
There?s one more wrinkle to this custom procedure. Setting the query string is not totally reliable, because there are places where it can be overridden at runtime. For example, when a user brings up a filter window by pressing the Filter button, the filter overrides any other query changes and applies the filter to the SDO?s base OPEN QUERY statement.
So to maintain the integrity of your filter, which should always be there, you need to take the query string that assignQuerySelection creates and make it the base query for the SDO. This base query is stored in the SDO?s BaseQuery property, so you must reset that property at initialization. By contrast, the current query definition, which is subject to change, is stored in another SDO property called QueryString.
So you must define one more variable to use to retrieve the value of the QueryString property after you reset it using assignQuerySelection, and then apply that value to the BaseQuery property, so that your basic filter will stick throughout the life of the running SDO instance.
</extract of John Sad's Dynamics Programming Handbook>
The point of the following sample code is to add a filter to the query of a Child SDO without breaking a join.
Implement the following code before SUPER in the initializeObject of the SDO (or is Data Logic Procedure).
Note that DB-REQUIRED has to be *unchecked* (required on the thin client side):
<pre>DEFINE VARIABLE cQueryString AS CHARACTER NO-UNDO.
DEFINE VARIABLE cASDivision AS CHARACTER NO-UNDO.
{get ASDivision cASDivision}.
IF cASDivision <> 'Server' THEN DO:
/* Not empty if a joined has already been implemented in it */
{get queryString cQueryString}.
/* If empty, then take the base query */
IF cQueryString = '' THEN {get baseQuery cQueryString}.
/* If the condition is not already there, then add it */
IF NOT cQueryString MATCHES '*order_code BEGINS "6"*' THEN DO:
cQueryString = DYNAMIC-FUNCTION ('newQueryValidate':U
IN TARGET-PROCEDURE , cQueryString
, 'order_code BEGINS "6"' ,'','').
/* setting the new query in BaseQuery before SUPER
in initalizeObject should be enough.... */
{set baseQuery cQueryString}.
/* ... but it seems the following is required if the SDO is used
in an SBO with DB-Bound session (seen with child SDO in 2.1A03)*/
{set QueryString cQueryString}.
END.
END.
RUN SUPER.</pre>