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

["Schmidt, Mihael" <Mihael.Schmidt@xxxxxxxxxxx>]

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