Kbase P19751: Why must dynamic queries set the FORWARD-ONLY attribute manually instead of using the -noautoreslist
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  16/01/2009 |
|
Status: Verified
GOAL:
Why must dynamic queries set the FORWARD-ONLY attribute manually instead of using the -noautoreslist startup parameter when it is specified?
FACT(s) (Environment):
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x
FIX:
All dynamic queries have a built-in result list. Static queries do not have a result list built in unless they are defined with SCROLLING, or are part of a static BROWSE etc.
When the -noautoreslist startup parameter was added, it was assumed that no recompiling would go on, that existing runtime code would have to keep working.
Since static queries have a clear way to tell if the intention of the programmer was to suppress SCROLLING (and that is actually known in the r-code), then it would be safe to stop those queries from building result-lists and GET PREVing, with the startup parameter.
But for dynamic queries, there is no such way to "guess" what the programmer intended, since these queries all defaulted to being scrolling, and there was no way to turn it off. So, when the -noautoreslist startup parameter is used, if these queries all suddenly started refusing to allow GET-PREV, then the startup parameter would be useless because it would kill the majority of dynamic queries (those in browses etc). So anyone wanting to make their non-scrolling static queries avoid a result-list, would at the same time lose all their browsing capabilities.
Of course, if you were not doing any browsing, any reposition to rowid etc., then you would be happy having the dynamic queries defaulting to the state of the startup parameter. But most people use a combination of queries, some forward only and some not. So they would suddenly find that nothing would work anymore once they enabled the startup parameter.