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

No. The variable is locally defined and exclusivly set in the SQL.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Birgitta Hauser
Sent: Thursday, May 06, 2010 2:29 PM
To: 'RPG programming on the IBM i / System i'
Subject: AW: Weird Embedded SQL Problem: getting x'20' in result variable

Could it be this field was filled by an Java any other program where Unicode
is used?

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] Im
Auftrag von Schmidt, Mihael
Gesendet: Thursday, 06. May 2010 13:07
An: RPG programming on the IBM i / System i
Betreff: RE: Weird Embedded SQL Problem: getting x'20' in result variable

I checked all messages generated in debug mode and have found nothing out of
the ordinay (cursor opened, cursor closed, etc...).

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Schmidt, Mihael
Sent: Thursday, May 06, 2010 10:02 AM
To: RPG programming on the IBM i / System i
Subject: RE: Weird Embedded SQL Problem: getting x'20' in result variable

Haven't done that yet. I'll give it a try.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of David FOXWELL
Sent: Thursday, May 06, 2010 9:26 AM
To: RPG programming on the IBM i / System i
Subject: RE: Weird Embedded SQL Problem: getting x'20' in result variable

Mihael,

Just a thought. I haven't read all your thread, but as see you still haven't
found the cause...

Weird, Embedded SQL, V6R1. Have you seen my post on EXECUTE failing ?

Have you tried checking all the SQL messages in your job while in debug
mode? We found some very interesting information, although weird, also.

-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Schmidt, Mihael
Envoyé : jeudi 6 mai 2010 08:29
À : RPG programming on the IBM i / System i
Objet : 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
--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i
(RPG400-L) mailing list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.