Fetching clobs as strings return truncated values when nsl_lang is UTF8

[bangusi]

Environment: Server: Oracle 12c ( on Linux ) NLS_CHARACTERSET = WE8MSWIN1252 NLS_NCHAR_CHARACTERSET = AL16UTF16

Client: 18.5c on Windows 10 ocilib: ANSI build UTF-8 env setting

I am trying to retrieve a view definition which has more than 18K characters.

stmt.Execute ( "select DBMS_METADATA.GET_DDL('VIEW','MYVIEW_NAME','SCHEMA') from dual" );

then calling auto val = rset.Get<ostring> ( 1 ); The view text gets truncated at around 16K.

What is a workaround so I get the full view text?

I can retrieve the full text using sqldeveloper client.

[vrogier]

Hi,

What are the db and client charset ? Do you have the same issue if you fetch as clob (as GET_DDL returns a clob) ? If you do fetch as clob, what if the value of clob.GetLength() ?

Vincent

[vrogier]

Can you provide a sample DDL for me to reproduce ?

[bangusi]

@vrogier I have updated my post with more info about my setup. Hope that helps

[vrogier]

When fetching clob as strings, OCILIB is using buffer chunks of 65 536 bytes, thus large enough to fetch your data without iterating and reallocating the buffer for the value. Thus can't be an issue in internal fetching of clob value to string. I created a table with a 32k clob data and been able to get a 32K string straight away.

[vrogier]

Arf, I have just tried using nls_lang set ot UTF8 and got truncated value. I will investigate this issue asap.

[vrogier]

Hi,

Issue fixed in 4.7.0 branch (will add test suite for that later today).

Regards,

Vincent

[vrogier]

current workaround, without the fix, would be to fetch as clob and read directly from clob.

[bangusi]

I thought there was an optional setting in the library equivalent to sqlplus set long N system variable

[vrogier]

it is not a question of long/clob size (there is also the same option for fetching longs in ocilib). The issue resided in the internal read loop making a string from a clob

[bangusi]

When do you plan on releasing 4.7.0? I am assessing whether to use a workaround ( fetch as clob ) or wait for the 4.7.0 release. My preference is to not use the workaround.

[vrogier]

HI,

v4.7.0 is pretty much ready. Time frame is about beginning of next week, around (July 13/14)

[bangusi]

ok. Thanks

[bangusi]

A couple of follow-up questions:

1. Is the v4.7.0 release still on track?
2. What is the expected behavior when you call GetString() (with UTF-setting) from an NCLOB? I have a generic ocilib client that fetches gibberish if the column is NCLOB but somehow Oracle SQLdeveloper is able to get the column value as a readable string

[vrogier]

Hi,

Yes, still on track but I haven a little bit busy. Expected it to be released before tomorrow evening unless point 2 needs more investigation. Can you create an issue for point 2 asap ?

Thanks

[vrogier]

Can you give details for the nclob issue? What is the national character set used ?

[bangusi]

Can you give details for the nclob issue? What is the national character set used ?

I have updated the ticket

[vrogier]

Hi,

v4.7.0 merged in Master. v4.7.0 has been released

Regards,

Vincent

[vrogier]

@bangusi Is everything working okay for you now with v4.7.0?

Vincent

[bangusi]

Yes. So far so good. Thanks. Unrelated: My build is broken since you re-organized the project. I used to build my own statically linked ocilib so I don't have to carry the dll around. The build now now seems my require more work so have to use the shipped version. But that is my problem not yours.