Srinadh,
The fact that your program behaves differently depending on the number of
rows in the table makes me suspect that there is something wrong in your
program, not in DB2. DB2 should not normally behave differently for 60 rows
than it does for 60,000,000 rows, except that it will take longer for the
program to finish when there is larger number of rows. However, the
behaviour of the individual statements, like an INSERT or UPDATE, shouldn't
change.
Or do you mean 60 *columns*, instead of rows? If you do mean columns instead
of rows, it is possible that you are concatenating too much data together;
remember, there is a limit to the size of a CLOB (2 GB, if I am not
mistaken, but may vary for some platforms and versions of DB2.)
I think we need to see your code to help you figure out this problem.
Can you post your code - or at least the critical part of it - and the
definitions of some of the tables, perhaps a table with less than 60 rows, a
table with 60 to 200 rows, and a table with over 200 rows?
What OS are you using? What version of DB2 are you using?
Also, have you looked at the SQLJ samples in the SQLLIB/samples/Java
directory of DB2? They usually give you a good idea how to do things like
updating/inserting with CLOBs.
Rhino
"Srinadh" <sr*****@gmail.com> wrote in message
news:2e**************************@posting.google.c om...
Hi all,
We have files with about 20 to 30 fields per row.
We are trying to update such files with about 60 rows as contiguous
data in a CLOB field.
It passes through.
But when we try updating files with about 60 to 200 rows, we get the
below exception,
[IBM][CLI Driver][DB2/NT] SQL0302N The value of a host variable in the
EXECUTE or OPEN statement is too large for its
corresponding use. SQLSTATE=22001
And When we try updating more than 200 rows, we get the below
exception
[IBM][CLI Driver][DB2/NT] SQL0973N Not enough storage is available in
the "QUERY_HEAP" heap to process the statement.
SQLSTATE=57011
we are using SQLJ to update/ insert the CLOB field.
Any pointers to this ?
Thank you,
Srinadh