php pdo connected to DB2 different CODEPAGE - php

Question

I'm connecting to DB2 DB
$sql = 'CALL procedures.name(1,1,'text',1,1,'2017-08-30','2017-08-31',?,?)';
try {
$con = new PDO("idb:all_the_connections_stuu",'user','pass',
[
PDO::ATTR_PERSISTENT => FALSE,
PDO::ATTR_ERRMODE => PDO:ERRMODE_EXCEPTION,
PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL,
PDO::ATTR_AUTOCOMMIT => 0
]
);
$stmt = $con->prepare($sql);
$stmt->bindParam(1, $errorNumber, PDO::PARAM_INT); //also trying without PDO::params
$stmt->bindParam(2, $errorCode, PDO::PARAM_STR, 800); //and with |PDO::PARAM_INPUT_OUTPUT
$stmt->execute(); //return *TRUE*
var_dump($errorNumber); //return NULL
var_dump($errorCode); //return NULL
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC)); //returns Error
$stmt->closeCursor();
$stmt = null;
} catch (PDOException $e) {
echo ($e->getMessage());
}
and got this error:
Fatal error: Uncaught PDOException: SQLSTATE[57017]: <<Unknown error>>: -332
[IBM][CLI Driver][DB2] SQL0332N
Character conversion from the source code page "" to the target code page "" is not supported.
SQLSTATE=57017
(SQLFetchScroll[-332] at /home/user/shared/PDO_IBM-1.3.4/ibm_statement.c:1306) in /var/www/html/server/testsIBM/index.php:80
Stack trace:
#0 /var/www/html/server/testsIBM/index.php(80): PDOStatement->fetchAll(7, 0)
#1 {main}
thrown in /var/www/html/server/testsIBM/index.php on line 80
If I connect with db2_connect
$con = db2_connect("DATABASE=DB2D;HOSTNAME=10.243.13.65;PORT=5000;PROTOCOL=TCPIP;USERNAME=asdf23;PASSWORD=asdfasf1","", "")
and output db2_client_info($con) and db2_server_info($con) I see that CONN_CODEPAGE from client = 819 and DB_CODEPAGE from server = 1208.
How can I set CONN_CODEPAGE in my client? I already set LANG in CentOs locale, but still got error of character conversion.
______upd:
Current $LANG = en_US.utf8 (also in locale -a I have en_US, en_US.iso88591, en_US.iso885915, en_US.utf8)
No matter what $LANG is set output from db2_client_info($con) still the same:
["APPL_CODEPAGE"]=>
int(819)
["CONN_CODEPAGE"]=>
int(819)
And same error about Character conversion from the source code page
I'm using PHP+Apache. Apache httpd.conf defaultCharset setting different locales didnt't change anything.
In php code setlocale don't changing anything either.
I think this setting store somewhere else, and ibm_db2 or pdo_ibm drivers use it. =|
____upd2
The only way I found out - change DB2CODEPAGE from installed db2 client. But I don't have installed client. I'm using inly libraries.
Now i installed v11.1.2fp2_linuxx64_client.tar.gz (1.03 GB). But i can't laucn db2 client. Think I need another new question =\
____upd3
After all manipulations with CentOs, apache locales - I still get -322 exception. No matter what I changed - db2_client_info($con) still shows me 819 CodePage. And all work nice, until fetch()/fetchAll()
CentOs 7.3, PHP 7.1.8 with PDO_IBM 1.3.4-patched, and ibm_db2. BUT I make this modules from PECL sources (cause server doesn't have internet connection).
And I also don't have any DB2 products installed on mine application server (thats why I decide that CodePage getting from CentOs locale). It seems from your test, that DB2 data server client is required?

Answer 1

If you are using the "IBM DB2 Data server driver for ODBC and CLI" specifically for your Centos client, you can try ensuring that the environment for the account that runs PDO and connects to DB2 has DB2CODEPAGE=1208. You can export this variable (only for this specific client type) via:
export DB2CODEPAGE=1208
and restart whatever process(es) are involved in your solution.
Also for the account(s) you are using to connect to DB2, their client LANG setting should be an UTF-8 locale (and that locale needs to be installed on your Centos). Use the command locale -a to show which locales are installed, and choose one which has an utf-8 for your territory. For example if your $LANG was en_us then change it to en_us.utf-8, if that locale is installed. Export that $LANG in the shell startup of the relevant accounts and restart your apps.
If you are using a full-DB2 client (or the local DB2-client on a DB2-server on unix) you also need to correctly set the LANG variable to a value compatible with the encoding of your DB2 database. Otherwise you will either get codepage conversion at run time, which may have unexpected results, including exceptions if no suitable conversion exists.
For information:
Tested PHP 7.0.20 with PDO_IBM 1.3.4-patched, and ibm_db2 , with DB2 V11.1.2.2 , on ubuntu 16.04 LTS - appl_codepage = conn_codepage = db_codepage.
Also tested PHP 5.3.3 with PDO_IBM 1.3.4-patched, and ibm_db2, with DB2 V10.5.0.7, on RHEL 6.9: appl_codepage = conn_codepage = db_codepage.
Also tested PHP 5.4.16 with PDO_IBM 1.3.4-patched and ibm_db2, with DB2 V11.1.2.2 data server client , on CENTOS 7.3: appl_codepage = conn_codepage = db_codepage.
Note: Ubuntu , RHEL, Centos had default locale set for utf-8, before building pdo_ibm from github, or installing ibm_db2 with pecl. All local and remote databases had utf-8 encoding.

Answer 2

You may find, trying the tips described here (with more explanations) very useful, notably :
Make the source and target code pages compatible with each other.
Search the DB2 information Center
using the phrase
"Code set Territory code" for compatibility of the supported DB2 code
pages. To set the client's code page compatible with the database code
page:
On Unix platforms, set the LANG, LC_CTYPE or LC_ALL environment
variable to a locale whose code page is compatible with the database
code page. Consult the platform documentation to see the valid locale
names and the code page associated with each of them.
On Windows
platforms, set the DB2CODEPAGE registry variable to override the
client's code page with a value compatible with the database code
page.
For database manager code page support, search the
DB2 information Center
using the phrase
"Code set Territory code". For federated system users, see the
Federated Systems Guide for data source code page. If the source and
target code pages are compatible, then DB2 currently does not support
this particular code page conversion. Contact your technical service
representative to determine if such support can be added.