Just to be sure: have you set TOracleSession.BytesPerCharacter to bcAutoDetect?

Hello, Marco,
Since some DOA users in JAPAN reported this same ORA-01480 error,
I'm currently investigating this with a small sample program.

With Server:
NLS_CHARACTERSET AL32UTF8
NLS_LENGTH_SEMANTICS BYTE
and Client:
NLS_LANG=JAPANESE_JAPAN.JA16SJISTILDE

I get ORA-01480 when I update a
VARCHAR2 (2020) column with a long (l>=1001) string.

BytesPerCharacter = 4,
MaxVarChar = 4000 / 4 = 1000.
----------
I've found that Session.MaxVarChar is so small that
TOracleQuery.BindVariables truncates the buffer too short.
----------
There seems to be a workaround.

function TOracleSession.MaxVarchar: Integer;
begin
if UseOCI80 then Result := 4000 else Result := 2000;
Result := Result div CharacterSize;
Result := 16000; //<< HERE is the worlkaround.
end;

By setting the MaxVarchar large enough,
DOA won't truncate the input varchar2 string any more.

But I'm not sure it is safe to do so yet.

Is this safe to set MaxVarchar = 160000 so that
it's large enough for VARCHAR2(4000 CHAR ) in AL32UTF8 ?

I hope the only bad thing with MaxVarchar=16000 is
larger memory consumption

Thanks, we'll check it out.

Yes the TOracleSession.BytesPerCharacter = bcAutoDetect.
I wil make a test program to check the workaround Kunikazu suggests. (thanks in advance for sharing this.)

Marco can you let me know if this is save to use?

I cannot yet say if it is safe. We have not yet tested this.

Hi Marco,

the workaround from Kunikazu does the trick. When can we expect an answer if it is ok to use in an productional environment.

thanks in advance

Ruud

I'm not sure yet. This will require some extensive testing.

Ok I understand,

i have to be more patient then "Szell" the dentist in "The Marathon man" ... "is it safe?" ;-)

kind regards

Has this issue been resolved yet?

We are facing the same issue - what is the status of this issue?
Can we expect a fix in the soon future?