Consultor Eletrônico

Status: Unverified

FACT(s) (Environment):

Progress 9.1D

SYMPTOM(s):

A WORK-TABLE (WORKFILE) does not behave like a TEMP-TABLE or a database table with recursive programming

CAUSE:

First, keep in mind that WORK-TABLE's are obsolete and that we keep them for backward compatibilty with old versions of Progress (like Version 6). TEMP-TABLE's are usually much faster (except in very few rare cases that are very hard to reproduce) especially when appropriate indexes are defined.

Indeed, it seems that there is an unexpected case when a WORK-TABLE does not behave like a TEMP-TABLE with recursive programming, but it is also due to a little programming mistake with the scope of buffers, as explained bellow:
The following code uses a buffer defined in the definition block, so not private to the internal procedure:
PROCEDURE myInternalProc
[some input params defined here]

FOR EACH myWorkTable WHERE... :
[...]
... RUN myInternalProc ([some input params]).
END.
END PROCEDURE.
The 4GL lets you compile that, but it is actually like doing:
FOR EACH myWorkTable WHERE... :
[...]
FIND myWorkTable WHERE...
END.
END PROCEDURE.
That is not allowed because the buffer for the FOR EACH would be spoiled by the FIND.
Strangely, it seems that the first code works as wanted when using temp-tables or database tables, but this is unexpected.

FIX:

You should actually use a private buffer for the internal procedure to make sure that the FOR EACH is not disturbed by playing with its buffer in some other children procedures, as illustrated bellow:

PROCEDURE myInternalProc
[some input params defined here]
DEFINE BUFFER bmyWorkTable FOR myWorkTable.

FOR EACH bmyWorkTable WHERE... :
[...]
... RUN myInternalProc ([some input params]).
END.
END PROCEDURE.
This way, each call of myInternalProc is playing with its own buffer and will not be disturbed by called procedures (as long as the data are not badly modified or deleted, but this is another topic)