FOR EACH with BY question...

ederf

New Member
Hi all,

I have two procedures updating,creating and deleting records from a specific temp-table.
The second procedure (here a simple example called p2.p) is invoked inside of a for each of that TT, and, in some cases a record is inserted.
With the by option, the for each doesn't read the record inserted by p2, without by it does!
Is there some workaround to "force" the reading of this record by the for each, changing only the p2.p :)? (Due to license issues, I cannot change the p1.p)

TIA.

Eder.

/*p1.p*/
def new shared temp-table tt no-undo
field codigo as int.

create tt.
assign tt.codigo = 1.
create tt.
assign tt.codigo = 3.
for each tt by tt.codigo:
message tt.codigo
view-as alert-box info buttons ok.
if tt.codigo = 1 then
run p2.p.
end.
/*End p1.p*/

/*p2.p*/
def shared temp-table tt no-undo
field codigo as int.
create tt.
assign tt.codigo = 2.
/*end p2.p*/
 
Intresting !! But The "look ahead" buffer cannot be referenced directly by the 4GL developer. Progress will generate INTERNAL buffer for preselect and BY. I think its almost impossible. May be a draw back!!
Regards
Philip P Oommen
 
I suppose the first question is why would you want to program this way? Obviously, your example is simplified to make your point, but it seems to me that the entire style is one where I would expect the behavior to be unpredictable.

Not to mention that you shouldn't be using shared variables either.
 
I very recently fixed a very similar bug where a report created and populated temp-table records but occasionally didn't report the last temp-table record created.

So, we had the following structure:

Code:
for each table where .... no-lock:
  run createtemptablerecord.
end.
 
 
for each ttable no-lock:
  display ttable.
end.

The fix was to put a find first ttable no-lock no-error. between the two for eaches.

So, the new code structure was:

Code:
for each table where .... no-lock:
  run createtemptablerecord.
end.
 
find first ttable no-lock no-error.
 
for each ttable no-lock:
  display ttable.
end.

So, you can try that and see if it works.

Ah, I've just noticed that you can't change the program that builds the temp-table, so this won't work.
 
An explicit release of the TT-buffer after creation would do the trick as well.

Casper.
 
Back
Top