Announcement

Collapse
No announcement yet.

Manipulate a character in a CLOB variable.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Manipulate a character in a CLOB variable.

    I used JSON_OBJECT to return me many rows of json data.

    The requestor asked me to add a comma between the rows of returned json.

    To return the full data string I used a CLOB variable.

    I populate the clob variable until end of data.

    That leaves me a comma after my last row of JSON. I would like to remove it.
    I am not sure how to accomplish this.
    The last line is my failed attempt.

    This is my first time using a CLOB and JSON_OBJECT.


    dcl-s count int(5:0) inz(1);
    dcl-s returnString sqltype(clob:400000);
    dcl-ds returnData likeds(listData) dim(9999);
    dcl-ds listData Qualified Occurs(9999);
    row varchar(1024);
    end-ds;


    mainList(returnData);

    returnString_data = %trim(returnString_data) + %trimr(returnData(count).row);
    dou returnData(count).row = *blanks;
    count += 1;
    returnString_data = %trim(returnString_data) + ','
    + %trimr(returnData(count).row);
    returnString_len = returnString_len + %len(%trimr(returnData(count).row));
    enddo;
    %subst(returnString_data: returnString_len -1 : 1) = ' ';



    Any help would be appreciated.



  • #2
    Where is your problem?
    ReturnString_Data is just a regular RPG fixed length character field.
    The only thing you have to consider, you have to recalculate the ReturnString_Len.

    ... but why to use a CLOB_Variable? Why not just using a regular RPG variable?

    Comment


    • #3
      I was having trouble with a char variable. I could not get it all into the variable.

      Comment


      • #4
        Why does the length need to be recalculated? Isn't it set to the final number after the DO loop?

        How would it be recalculated?

        Comment


        • #5
          The problem is that the comma is not being cleared by the last line of the code

          Comment


          • #6
            I'd code it so that you don't need to clear the comma. I'd also try to eliminate as many of the horrible %TRIM calls as possible -- constantly trimming a 400000 character field is very bad for performance and seems completely unneeded. I don't know if the one around returnData(count).row is needed? Will mainList() put trailing blanks on the row? If not, you could remove those %TRIMRs as well.

            The general idea is something like this:
            Code:
            dcl-s tempString varchar(400000);
            
            mainList(returnData);
            
            count = 1;
            dow returnData(count).row <> *blanks;
              if count = 1;
                tempString += %trimr(returnData(count).row);
              else;
                tempString += ',' + %trimr(returnData(count).row);
              endif;
              count += 1;
            enddo;
            
            returnString_data = tempString;
            returnString_len  = %len(tempString);

            Comment


            • #7
              The only reason to use a CLOB in RPGLE is if the variable will be used by SQL, as SQL cannot use VARCHARs> 32k. And even then, a CLOB has exactly ther same structure as a VARCHAR with a 4 byte prefix, so you can just pointer overlay a sqltype(CLOB:x) variable with a varchar(x:4) variable. RPGLE code can use the varchar using all the native BIFs, and SQL can use the CLOB, and they are always the same.

              Regarding Scott's solution, I would consider add an array size test to the loop. Otherwise you risk the program falling over if the array is completely full.

              Code:
              count = 1;
              dow count <= %len(returnData) and returnData(count).row <> *blanks;
                if count = 1;
                  tempString += %trimr(returnData(count).row);
                else;
                  tempString += ',' + %trimr(returnData(count).row);
                endif;
                count += 1;
              enddo;
              P.S. an array DS works better in every way than an OCCURS DS, so the only reason to sue OCCURS is when dealing with a legacy program that already uses it.

              Comment


              • #8
                Thank you for the great suggestions. I took from both.

                The reason I used an occurs was I could not get the JSON_OBJECT to put the json data into an array.

                I receive the following error when I try to put it into an array rather them a MultiOccur DS.

                *RNF5343 30 1 Array has too many omitted indexes; specification is ignored.

                Edit: I was able to drop the Multi Occur DS
                Last edited by corvair61; 1 day ago.

                Comment

                Working...
                X