Is this a bug or is my expectation wrong?

[Cecil]

Hi all.

The first example code works and I have no problems with it.

The second example is all most I identical except that I there is no array extent size specified for the chInputValue variable. I set the extent size of the variable after I have defined it.

Now when I run the second example code the chInputValue variable only imports the first entry in the export file.

Is this a BUG or is this the expected behaviour?

Please try the first example and then try the second example. Thanks.

Details:
OE 10.2ASP2
OS Linux and Windows.

/** 1st Sample Code. **/
DEFINE STREAM sOutput.
DEFINE STREAM sInput.

DEFINE VARIABLE chOutputValue AS CHARACTER   NO-UNDO EXTENT 4 INITIAL ["CAT","DOG","RABBIT","RAT"].
DEFINE VARIABLE chInputValue  AS CHARACTER   NO-UNDO EXTENT 4. 

OUTPUT STREAM sOutput TO 'extentexport.txt'.
EXPORT STREAM sOutput DELIMITER ',' chOutputValue.
OUTPUT STREAM sOutput CLOSE.

/* EXTENT(chInputValue) = EXTENT(chOutputValue). */

INPUT STREAM sInput FROM 'extentexport.txt'.
IMPORT STREAM sInput DELIMITER ',' chInputValue.
INPUT STREAM sInput CLOSE.

DEFINE VARIABLE i AS INTEGER     NO-UNDO.
DO i = 1 TO EXTENT(chInputValue):
    DISPLAY 
        i               LABEL 'Extent'
        chInputValue[i] LABEL 'Input Value'
        WITH SIDE-LABELS  .
    PAUSE.
END.

/** 2nd Sample Code. **/
DEFINE STREAM sOutput.
DEFINE STREAM sInput.

DEFINE VARIABLE chOutputValue AS CHARACTER   NO-UNDO EXTENT 4 INITIAL ["CAT","DOG","RABBIT","RAT"].
DEFINE VARIABLE chInputValue  AS CHARACTER   NO-UNDO EXTENT. 

OUTPUT STREAM sOutput TO 'extentexport.txt'.
EXPORT STREAM sOutput DELIMITER ',' chOutputValue.
OUTPUT STREAM sOutput CLOSE.

EXTENT(chInputValue) = EXTENT(chOutputValue). 

INPUT STREAM sInput FROM 'extentexport.txt'.
IMPORT STREAM sInput DELIMITER ',' chInputValue.
INPUT STREAM sInput CLOSE.

DEFINE VARIABLE i AS INTEGER     NO-UNDO.
DO i = 1 TO EXTENT(chInputValue):
    DISPLAY 
        i               LABEL 'Extent'
        chInputValue[i] LABEL 'Input Value'
        WITH SIDE-LABELS  .
    PAUSE.
END.

 

[jkuhns]

Both examples work in 10.1C.

 

[GregTomkins]

Didn't somebody post on PT the other day that you can't alter the EXTENT of an array after it's been created?

 

[Casper]

This is really weird. It should hold the values of the 4 values but instead it just seems to assign the first value to the entire aray.
The same in 10.2A02 as in 10.2B (just tested).

It certainly isn't expected behavior to me. I tried many variatons on this but it seems that the import statements is treating the indetermined array as a variable and just assign it. (eg chInputValue = ...).

I added another extent and there the same happens for the second field:

DEFINE STREAM sOutput.
DEFINE STREAM sInput.
DEFINE VARIABLE chOutputValue AS CHARACTER   NO-UNDO EXTENT 4 INITIAL ["CAT","DOG","RABBIT","RAT"].
DEFINE VARIABLE chInputValue  AS CHARACTER  EXTENT NO-UNDO. 
DEFINE VARIABLE chInputValue1  AS CHARACTER  EXTENT NO-UNDO. 

OUTPUT STREAM sOutput TO 'extentexport.txt'.
EXPORT STREAM sOutput DELIMITER ',' chOutputValue.
OUTPUT STREAM sOutput CLOSE.

DEFINE VARIABLE i AS INTEGER     NO-UNDO.
ASSIGN EXTENT(chInputValue) = EXTENT(chOutputValue)
       EXTENT(chInputValue1) = EXTENT(chOutputValue).
INPUT STREAM sInput FROM 'extentexport.txt'.
IMPORT STREAM sInput DELIMITER ',' chInputValue chInputValue1.
INPUT STREAM sInput CLOSE.
DO i = 1 TO EXTENT(chInputValue):
    DISPLAY 
        i               LABEL 'Extent'
        chInputValue[i] LABEL 'Input Value' FORMAT 'X(8)'
        chInputValue1[i] LABEL 'Input Value1' FORMAT 'X(8)'
        WITH SIDE-LABELS  .
    PAUSE.
END.

IMO its a bug.

Regards
Casper.

 

[Cecil]

I've now tested this under OE 11 on Windows XP, and there is still a issue. I guess this has never been an problem to other developers to raise a support case/call.

I think I will raise a quick support call to progress just to get an official answer.

 

[Cecil]

Got some updates on this.

Firstly, Progress Software Development Team have said that the import issue is expected behavior, as it has been like that for years ("it's expected behavior, because it's been wrong for years", WTF!!!). They won't change it because there could be too many applications that already rely on this behavior and therefore you will need to use the workaround as the way to do it, unfortunately.

I should of raised a bug 2 years ago.