Error reading data from CLOB column into VARCHAR2 variable

Question

Hi all,
Am hitting an issue retrieving data > 8K (minus 1) stored in a CLOB column into a VARCHAR2 variable in PL/SQL...
The "problem to be solved" here is storing DDL, in this case a "CREATE VIEW" statement, that is longer than 8K for later retrieval (and execution) using dynamic SQL. Given that the EXECUTE IMMEDIATE statement can take a VARCHAR2 variable (up to 32K(-1)), this should suffice for our needs, however, it seems that somewhere in the process of converting this VARCHAR2 text to a CLOB for storage, and then retrieving the CLOB and attempting to put it back into a VARCHAR2 variable, it is throwing a standard ORA-06502 exception ("PL/SQL: numeric or value error"). Consider the following code:
set serveroutput on
drop table test1;
create table test1(col1 CLOB);
declare
cursor c1 is select col1 from test1;
myvar VARCHAR2(32000);
begin
myvar := '';
for i in 1..8192 loop
myvar := myvar || 'a';
end loop;
INSERT INTO test1 (col1) VALUES (myvar);
for arec in c1 loop
begin
myvar := arec.col1;
dbms_output.put_line('Read data of length ' || length(myvar));
exception when others then
dbms_output.put_line('Error reading data: ' || sqlerrm);
end;
end loop;
end;
If you change the loop upper bound to 8191, all works fine. I'm guessing this might have something to do with the database character set -- we've recently converted our databases over to UTF-8, for Internationalizion support, and that seems to have changed underlying assumptions regarding character processing...?
As far as the dynamic SQL issue goes, we can probably use the DBMS_SQL interface instead, with it's EXECUTE procedure that takes a PL/SQL array of varchar2(32K) - the only issue there is reading the data from the CLOB column, and then breaking that data into an array but that doesn't seem insurmountable. But this same basic issue (when a 9K text block, let's say, turns into a >32K block after being CLOBberred) seems to comes up in other text-processing situations also, so any ideas for how to resolve would be much appreciated.
Thanks for any tips/hints/ideas...
Jim

Answer 1

For those curious about this, here's the word from Oracle support (courtesy of Metalinks):
RESEARCH
========
Test the issue for different DB version and different characterset.
--Testing the following PL/SQL blocks by using direct assignment method(myvar := arec.col1;) on
different database version and different characterset.
SQL>create table test1(col1 CLOB);
--Inserting four CLOB data into test1.
declare
myvar VARCHAR2(32767);
begin
myvar := RPAD('a',4000);
INSERT INTO test1 (col1) VALUES (myvar);
myvar := RPAD('a',8191);
INSERT INTO test1 (col1) VALUES (myvar);
myvar := RPAD('b',8192);
INSERT INTO test1 (col1) VALUES (myvar);
myvar := RPAD('c',32767);
INSERT INTO test1 (col1) VALUES (myvar);
commit;
end;
--Testing the direct assignment method.
declare
cursor c1 is select col1, length(col1) len1 from test1;
myvar VARCHAR2(32767);
begin
for arec in c1 loop
myvar := arec.col1;
--DBMS_LOB.READ(arec.col1, arec.len1, 1, myvar);
dbms_output.put_line('Read data of length: ' || length(myvar));
end loop;
end;
The following are the summary of the test results:
===================================
1. If the database characterset is WE8ISO8859P1, then the above direct assignment
method(myvar := arec.col1;) works for database version 9i/10g/11g without any
errors.
2. If the database characterset is UTF8 or AL32UTF8, then the above direct assignment method(myvar := arec.col1;) will generate the "ORA-06502:
PL/SQL: numeric or value error" when the length of the CLOB data is greater
than 8191(=8K-1). The same error can be reproduced across all database versions
9i/10g/11g.
3. Using DBMS_LOB.READ(arec.col1, arec.len1, 1, myvar) method to read CLOB data into a VARCHAR2 variable works for both WE8ISO8859P1 and UTF8
characterset and for all database versions.
So - it seems as I'd surmised, UTF8 changes the way VARCHAR2 and CLOB data is handled. Not too surprising, I suppose - may you all be lucky enough to be able to stay away from this sort of issue. But - the DBMS_LOB.READ workaround is certainly sufficient for the text processing situations we find ourselves in currently.
Cheers,
Jim C.