Consultor Eletrônico

Status: Unverified

GOAL:

Why should you use the AddQueryWhere against a Stateless AppServer?

FACT(s) (Environment):

Progress 9.1x

FIX:

RN# 091A-00583
Query Changes made with SetQueryWhere not used when context is reset:
If the query of a Stateless SDO is changed with SetqueryWhere, the criteria is lost when the SDO reconnect.
The problem can be worked around by using AddQueryWhere and SetQuerySort instead.


addQueryWhere
The addQueryWhere function takes three INPUT parameters:

The new WHERE clause to be added to the existing one.

An optional buffer name to specify which buffer in a join to append the WHERE clause to.

An optional Operator to connect multiple WHERE clause fragments passed in successive calls. The default is AND, but you can also specify OR.

If you do not specify the buffer name parameter, then you must qualify the field names in your WHERE clause with their table name in order to allow the function to build the WHERE clause most efficiently, with each phrase appended to the query join clause where that table appears in the join sequence. The SDO property QueryString stores successive changes to the WHERE clause. This property is stored in the client SDO (if the SDO is split between client and server). When openQuery is run, it checks to see if the QueryString property has a value, and if so, sends it to the server, prepares the database query using that value, and then opens the query. This allows your code to build up a complex WHERE clause efficiently, without preparing or opening the intermediate steps (or even sending them to the server) until the signal is given to open the database query.

For example, if you create a new SmartWindow called waddwhere.w, you can use the addQueryWhere function to allow filtering of a query. To show how the function operates on a joined query, use a SmartDataObject called djoin.w, which joins ?EACH Order, Customer OF Order, SalesRep OF Order?. There is a field called Where-Field in the Window which you can use to enter a new WHERE clause phrase, with this trigger code:

/* ON LEAVE OF Where-Field */ DO:
IF Where-Field:SCREEN-VALUE NE '' then
DO:
DYNAMIC-FUNCTION('addQueryWhere' IN h_djoin,
Where-Field:SCREEN-VALUE, '','').
Editor-1:SCREEN-VALUE IN FRAME {&FRAME-NAME} =
DYNAMIC-FUNCTION('getQueryString' IN h_djoin).
END.
END.

The Open button in the window leaves the Where-Field blank and runs openQuery:

/* ON CHOOSE OF Button-Open */
DO:
Where-Field:SCREEN-VALUE = ''.
DYNAMIC-FUNCTION('openQuery' IN h_djoin).
END.

The Reset button has the following code, which undoes all previous changes by invoking setQueryWhere with a blank parameter, closing the existing query; and leaving the other fields in the Window blank:

/* ON CHOOSE OF Button-Reset */
DO:
DYNAMIC-FUNCTION('setQueryWhere' IN h_djoin, '').
DYNAMIC-FUNCTION ('closeQuery' IN h_djoin).
editor-1:SCREEN-VALUE IN FRAME {&FRAME-NAME} = ''.
Where-Field:SCREEN-VALUE IN FRAME {&FRAME-NAME} = ''.
END.

After running the function, you can display the QueryString property in an Editor so that you can see the results. First, enter a WHERE clause for the Order table. Because you set the OpenOnInit property to FALSE in this Window, the database query does not open when the Window starts up. Notice that even after entering this WHERE clause, the Browser is still empty; the database query does not open until you press the Open button.