Salesforce

Why must dynamic queries set the FORWARD-ONLY attribute manually instead of using the -noautoreslist startup parameter when it is specified?

« Go Back

Information

 
TitleWhy must dynamic queries set the FORWARD-ONLY attribute manually instead of using the -noautoreslist startup parameter when it is specified?
URL NameP19751
Article Number000136909
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x
OS: All supported platforms
Other: N/A
Question/Problem Description
Why must dynamic queries set the FORWARD-ONLY attribute manually instead of using the -noautoreslist startup parameter when it is specified?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
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.
Workaround
Notes
Keyword Phrase
Last Modified Date9/13/2015 11:45 PM

Powered by