× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. RPG400-L
  3. May 2010

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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.