Consultor Eletrônico

Status: Unverified

SYMPTOM(s):

When using setQueryWhere in state-reset or state-aware, the queryContext is not being set on the client, so any other criteria that is added to the query through assignQuerySelection is always being appended to the original queryString.

Using assignQuerySelection to build the query string prior to reopening the query with the new criterea. In order to avoid appended previously defined criteria, call setQueryWhere passing a blank value to its parameter, followed by the call to assignQuerySelection.

In 9.1C, or in 9.1Dx locally or in stateless mode, this works.

In 9.1Dx with a state-reset or state-aware appserver, the setQueryWhere is inefective and all additional criterea are appended to the original query

STEPS TO REPRODUCE:
1) Create a simple SMO application with an SDO, a SDV, a STB and a button.

2) From the button's CHOOSE trigger call the following:

a) setQueryWhere, passing ''.
b) assignQuerySelection, passing some criterea to modify the query.
c) openQuery.
d) Message out the results from a call to getQueryWhere.

3) Setup a state-aware or state-reset appserver and run this code using the
appserver.

4) Press the button.

Notice that this works the first time and the message indicates that the
specified criteria was appended to the query.

5) Press the button again and notice that the message indicates that the
criteria was, again, appended to the query, it's in there twice.

Now imagine the effect that this would have if the criteria changed on
subsequent calls, this would potentially cause the query to bring back the
wrong, or no, results.

CAUSE:

Bug # 20020913-012

CAUSE:

It seems that, in state-reset and state-aware, the appserver is either not
getting the reset query string or it's depending on the client's
queryContext, which is not being set intentionally for state-aware and
state-reset.

The code in setQueryWhere(dataext.p) that checks the operating mode prior to
setting queryContext seems to be responsible for this. If the line of code
that verifies that the session is local or stateless is commented out the
problem goes away.

FIX:

Fixed in 9.1D02 and 9.1E.