×
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.
Henrik,
I have not followed the complete thread, but do you have a simple example
of what you are trying to do?
It is possible with DB2 for i SQL to specify the CCSID of a host variable,
which will affect what conversions DB2 will attempt.
See the DECLARE VARIABLE syntax in the infocenter:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp
See also the following note about references to host variables in the
infocenter
(
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Fdb2%2Frbafzch2host.htm)
The CCSID of a string host variable is either:
* The CCSID specified in the DECLARE VARIABLE statement, or
* If a DECLARE VARIABLE with a CCSID clause is not specified for the host
variable, the default CCSID of the application requester at the time the
SQL statement that contains the host variable is executed unless the CCSID
is for a foreign encoding scheme other than Unicode (such as ASCII). In
this case, the host variable is converted to the default CCSID of the
current server.
In general, as long as DB2 knows what the CCSID of the host variable is, it
will do the right conversions when providing or retrieving data.
Unless I have overlooked something the RPGLE UTF-8 field support is
more or less useless since it in reality only supports characters in the
jobs SBCS EBCDIC CCSID :-(
It would be far better that the DB just passed the data "as is bytes"
so it could be passed to either a the jobs SBCS EBCDIC field or to
a DBCS field by using a %BIF.
Nick Lawrence
DB2 for IBM i
(507) 253-0843 Tie 8-553-0843
ntl@xxxxxxxxxx
Success is not final, failure is not fatal: it is the courage to continue
that counts.
- Winston Churchill
midrange.com
