Bug #5373
BROWSE issues when QUERY is re-assigned to different buffers, and the original buffers are already bound
Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:
0%
billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
History
#2 Updated by Constantin Asofiei about 3 years ago
In OpenEdge, a static BROWSE can have its query changed, and this query can uses different buffers (for which their temp-tables are compatible with the definition query's temp-tables); after this, during population of the BROWSE, any access via the original/definition buffers, will reference the record as it appears in the current query, even if is from another temp-table.
In #5342 and 3821c rev 12420, this issue was fixed by binding the definition/original query buffers with the current query buffers.
There is another case which was explored in thebrwsproc.p
and brwsrun.p
programs, from testcases/uast/browse/binding/
folder:
- what if the original/definition buffers are already bound to some other 'master buffer' MB?
- how are these 'master buffers' behaving? Are they bound to the BROWSE query buffers, during population?
- how are the 'definition buffers' behaving? Are they bound to the BROWSE query buffers, during population? Are they restored after the BROWSE population?
Does this work with BIND, BY-REFERENCE, REFERENCE-ONLY?
#3 Updated by Greg Shah about 3 years ago
- Project changed from Base Language to User Interface
I'm moving this to the UI project snce the behavior is primarily (perhaps only) associated with BROWSE
.