FWD » Core Development » Base Language

This issue is a continuation of #9298. There is this testcase from #9298-43:

def temp-table tt1 like book.

// these two are 'no-reference' so a schema scope is added to isolate the promotion and not propagate
// (already solved, just to mention)
def dataset ds1 for tt1.
define data-source dr1 for tt1. 

procedure proc1.
   def buffer book for book.

   l1: for each tt1:
      // 'l1' scope must overwrite 'tt1' with 'book' - as unqualified field names have precedence on 'book' over 'tt1'
      // also, tt1's fields are propagated early (when the overwrite with 'book' is done) to the 'proc1' scope, otherwise they gets lost
      create book.

      message "book:" isbn. // must reference book.isbn

      // 'except isbn' here must reference tt1 - but tt1 can't be promoted again to 'l1', because of 'book'
      // so, how do we both, considering that buffer-copy is 'free-reference':
      // 1. promote tt1 so 'except' targets the source buffer
      // 2. do not affect 'l1' scope of 'book'
      // -> can a schema scope be used for this? 
      // -> otherwise, 'resolveLvalueCoreType' needs to explicitly use the source buffer
      // (same issue for buffer-compare).
      buffer-copy tt1 except book-id isbn to book.

      message "book:" isbn. // must reference book.isbn.
   end.

   message "book:" isbn. // must reference book.isbn. After testing, it seems it actually references tt1 here.
end.

run proc1.

In 4GL, I have compiled this program with XREF in order to be sure the reference records from the comments are really accurate. However, for the last message it doesn't state which buffer is being used. However, when running this example, for the last message, I get No tt1 record available. This will mean we actually should reference tt1 there, instead of book. This seems really strange to me. Basically, inside the for each tt1 we should reference book, however, after exiting, we should reference tt1. I have also tried removing all the code inside the for each, and I get the same behaviour.

Constantin, given that the changes done for #9298 don't really impact the testcase posted on #10601 and if by testing other applications, it won't regress anything else, can we just commit that to trunk, and, then get back to fixing the issue exposed on this task? The purpose for that will just be to get rid of the custom patches needed for 7156.

This is the testcase that is solved by the changes from #9298:

define buffer b_t1 for t1.
for each b_t1 where b_t1.f1 = 2:
end.
find first t1.
message f1. // With trunk this gets converted to:  message((character) new FieldReference(bT1, "f1").getValue());, with the 9298 changes: message((character) new FieldReference(t1, "f1").getValue());