RE: Weird Embedded SQL Problem: getting x'20' in result variable

The CCSID of the file is 273. We have not set anything "special" on the field so the CCSID of the field is also 273. Job CCSID is also 273. The PGM Module also has CCSID 273.

Actually I don't think it is a CCSID problem.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, May 05, 2010 3:45 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Weird Embedded SQL Problem: getting x'20' in result variable

Schmidt, Mihael wrote:

I am having a really weird embedded sql problem. I am just
retrieving a value from a database field, nothing special. The
database field is defined VARCHAR(32000). The value in the field
is about 200 characters long. The receiving variable is defined
32000A.

Most of the time the variable is filled correctly and is padded
with spaces (x'40'). But some times the variable is padded with
x'20' instead of x'40' and I got no clue why. The retrieved value
though is correct. Only the padded space is wrong.

We are on 6.1.

The outcome could be correct, depending on information that was
not provided. What is the CCSID of the VARCHAR? What is the CCSID
of the job in each scenario\outcome. Are any special features for
data typing & CCSID attributes being used for the RPG variable [and
supported by the SQL pre-compiler], such as emulating C-strings or
ASCII data type\attributes?

Schmidt, Mihael wrote:

Defining the variable as VARYING solved the problem.

Originally I fetched multiple rows with one statement. Changing
that to single row fetch also solved the problem (even without
changing the variable to VARYING).

SQLCODE is always 0. It is a nullable field but the null
indicator is also 0.

So I can't explain it but now I have a good workaround.

If there was really a problem with the fixed-length declaration
seeing the wrong pad character, it should be obvious that the wrong
pad character could have a resulting varying-length string, just as
easily seen\presented as the wrong value. That is, IMO I think it
is worth investigating the origin for why the unexpected results
were seen, rather than to simply assume that the problem is
circumvented.

Regards, Chuck