By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,236 Members | 1,355 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,236 IT Pros & Developers. It's quick & easy.

CLI Driver CLI0111E Value out of range SQLSTATE=22003

P: n/a
Hi,

I am getting this error while selecting some information from
syscat.columns in DB2.

DB2LEVEL is

db2level
DB21085I Instance "db2prod4" uses "32" bits and DB2 code release
"SQL08021"
with level identifier "03020106".
Informational tokens are "DB2 v8.1.1.80", "s041221", "U800400", and
FixPak "8".
Product is installed at "/usr/opt/db2_08_01".

Is my error related to the fact that I am not using the lastest
service pack ?

Is there any parameter that I can setup in my CLI connection in order
to avoid this?

Thanks,

Jean-Guy Roy

Aug 9 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
JohnnyDeep wrote:
Hi,

I am getting this error while selecting some information from
syscat.columns in DB2.

DB2LEVEL is

db2level
DB21085I Instance "db2prod4" uses "32" bits and DB2 code release
"SQL08021"
with level identifier "03020106".
Informational tokens are "DB2 v8.1.1.80", "s041221", "U800400", and
FixPak "8".
Product is installed at "/usr/opt/db2_08_01".

Is my error related to the fact that I am not using the lastest
service pack ?
I wouldn't think so. Your application seems to have an issue.

$ db2 "? cli0111"

CLI0111E Numeric value out of range.

Explanation:

Returning the numeric data would have caused the whole part of
the number to be truncated.

SQLPutData was called more than once for a parameter and the
input data was not of type character or binary.

User Response:

Respecify the output bindings either through SQLBindCol or
SQLGetData to avoid creating a numeric data truncation.

Do not call SQLPutData for a parameter if the application data
type specified for that parameter through SQLSetParam or
SQLBindParameter is not SQL_C_CHAR or SQL_C_BINARY.
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Aug 10 '06 #2

P: n/a
When I am running my same application against another DB2 database
selecting the same information from syscat.columns (I have the exact
same table in both database) everything is fine.

DB2LEVEL where the select is working is

DB21085I Instance "db2prod" uses "64" bits and DB2 code release
"SQL08023"
with level identifier "03040106".
Informational tokens are "DB2 v8.1.1.96", "s050811", "U803920", and
FixPak
"10".
Product is installed at "/usr/opt/db2_08_01".
Any idea?

Knut Stolze wrote:
JohnnyDeep wrote:
Hi,

I am getting this error while selecting some information from
syscat.columns in DB2.

DB2LEVEL is

db2level
DB21085I Instance "db2prod4" uses "32" bits and DB2 code release
"SQL08021"
with level identifier "03020106".
Informational tokens are "DB2 v8.1.1.80", "s041221", "U800400", and
FixPak "8".
Product is installed at "/usr/opt/db2_08_01".

Is my error related to the fact that I am not using the lastest
service pack ?

I wouldn't think so. Your application seems to have an issue.

$ db2 "? cli0111"

CLI0111E Numeric value out of range.

Explanation:

Returning the numeric data would have caused the whole part of
the number to be truncated.

SQLPutData was called more than once for a parameter and the
input data was not of type character or binary.

User Response:

Respecify the output bindings either through SQLBindCol or
SQLGetData to avoid creating a numeric data truncation.

Do not call SQLPutData for a parameter if the application data
type specified for that parameter through SQLSetParam or
SQLBindParameter is not SQL_C_CHAR or SQL_C_BINARY.
--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Aug 10 '06 #3

P: n/a
JohnnyDeep wrote:
When I am running my same application against another DB2 database
selecting the same information from syscat.columns (I have the exact
same table in both database) everything is fine.

DB2LEVEL where the select is working is

DB21085I Instance "db2prod" uses "64" bits and DB2 code release
"SQL08023"
with level identifier "03040106".
Informational tokens are "DB2 v8.1.1.96", "s050811", "U803920", and
FixPak
"10".
Product is installed at "/usr/opt/db2_08_01".
Any idea?
Try to collect a CLI trace. This will give you detailed information on the
statements that your application fires against DB2 and also the results and
values. Thus, you can pinpoint exactly where the CLI0111 occurs.

You could also try this with the other system so that you can figure out
where the differences in both systems are. I'm pretty confident that there
_are_ differences...

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Aug 10 '06 #4

P: n/a
Thank Knut,

I did trap the problem looking at the trace. The problem came from
the select calling the
table(snapshot_container()) function. On one database, the select
return nothing because the database is EEE and on the client we are
pointing to the catalog partition where the tablespace is not present.
On the other database (which is EE), the tablespace is present and the
container_name generate problem in the application (probably because of
the "/" in the path of the container). My application hardcode the
second parameter for the function table(snapshot_container()) to -1
which mean the current partition.

Anyway, thank for the tips Knut. It appreciate.
Knut Stolze wrote:
JohnnyDeep wrote:
When I am running my same application against another DB2 database
selecting the same information from syscat.columns (I have the exact
same table in both database) everything is fine.

DB2LEVEL where the select is working is

DB21085I Instance "db2prod" uses "64" bits and DB2 code release
"SQL08023"
with level identifier "03040106".
Informational tokens are "DB2 v8.1.1.96", "s050811", "U803920", and
FixPak
"10".
Product is installed at "/usr/opt/db2_08_01".
Any idea?

Try to collect a CLI trace. This will give you detailed information on the
statements that your application fires against DB2 and also the results and
values. Thus, you can pinpoint exactly where the CLI0111 occurs.

You could also try this with the other system so that you can figure out
where the differences in both systems are. I'm pretty confident that there
_are_ differences...

--
Knut Stolze
DB2 Information Integration Development
IBM Germany
Aug 11 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.