CODEWITHSUNDEEP
progress-4glopenedge
thomasw_lrd
thomasw_lrd

Reputation: 546

OpenEdge Progress 4GL Query returns (MISSING) after % sign

DEFINE TEMP-TABLE tt_pay_terms NO-UNDO
            FIELD pt_terms_code LIKE payment_terms.terms_code
            FIELD pt_description LIKE payment_terms.description.
        DEFINE VARIABLE htt AS HANDLE NO-UNDO.
        htt = TEMP-TABLE tt_pay_terms:HANDLE.

        FOR EACH platte.payment_terms
        WHERE (
            active = true
            AND system_id = "000000"
        )
        NO-LOCK:
        CREATE tt_pay_terms.
        ASSIGN
            pt_terms_code = payment_terms.terms_code.
            pt_description = payment_terms.description.
        END.

        htt:WRITE-JSON("FILE", "/dev/stdout", FALSE).

I have written this query and it returns data like this

[pt_terms_code] => 0.4%!N(MISSING)ET46
[pt_description] => 0.4%! (MISSING)DAYS NET 46

While I believe (from using a SQL query) that the data should be 

0.4%45NET46 
0.4% 45 DAYS NET 46

I'm making an assumption that the % is probably some special character (as I've run into similar issues in the past). I've tried pulling all the data from the table, and I get the same result, (ie, not creating a temp table and populating it with all the only the two fields I want).

Any suggestions around this issue?

I'm still very new to 4gl, so the above query might be terribly wrong. All comments and criticisms are welcome.

Upvotes: 0

Views: 162

Answers (1)

Tom Bascom
Tom Bascom

Reputation: 14020

I suspect that if you try this:

FOR EACH platte.payment_terms NO-LOCK
   WHERE ( active = true AND system_id = "000000" ):

  display
    payment_terms.terms_code
    payment_terms.description
  .

END.

You will see what the query actually returns. (WRITE-JSON is adding a layer after the query.) You will likely discover that your data contains something unexpected.

To my eye the "%" looks more like formatting -- the terms are likely 0.4%.

You then seem to have some issues in the contents of the description field. My guess is that there was a code page mismatch when the user entered the data and that there is gibberish in the field as a result.

Upvotes: 0

Related Questions