ORA-22275: invalid LOB locator specified , do we really have LOB columns in table

 ORA-22275: invalid LOB locator specified , do we really have LOB columns in table:

I came across a customer problem that query returning ORA-22275: invalid LOB locator specified error  from application logs when they ran a query that has join conditions with just two tables . none of the tables in the query have LOB columns, it all number, char , varchar2 data type columns.

the interesting part is the same query get executed from sqlplus command prompt. sql developer and other tool but not from JDBC connection made applications. the query gave same error when running from OEM worksheet too.

 

SELECT

     ..

    cmtf.t_context,

    ..

FROM

    table1       cmt

    LEFT OUTER JOIN 

    table1_fld   cmtf ON cmt.per_name = cmtf.per_name

WHERE

    cmt.per_name = 'MAX RANO KING'

ORDER BY

    cmtf.seq_num,

    cmtf.LOC_NAME; 

there may some other methods to investigate but the method I followed is :

1. check table have lob columns, none of them have lob columns

2. t_context column in both tables has VARCHAR2(4000)

column that has VARCHAR2(4000) really creates the issue???  perhaps testing I did made me to believe is YES. read on How

I ran this query to see what session NLS parameter get set from calling environment.

SELECT DB.PARAMETER, DB.VALUE "DATABASE", I.VALUE "INSTANCE", S.VALUE "SESSION" FROM   NLS_DATABASE_PARAMETERS DB, NLS_INSTANCE_PARAMETERS I, NLS_SESSION_PARAMETERS S WHERE  DB.PARAMETER=I.PARAMETER(+) AND DB.PARAMETER=S.PARAMETER(+) and db.parameter ='NLS_LENGTH_SEMANTICS' ORDER BY DB.PARAMETER;

SQL command prompt, sql developer and other GUI tools NLS_LENGTH_SEMANTICS=BYTE and query get executed successfully whereas in OEM worksheet (perhaps the same case in application session too), the  NLS_LENGTH_SEMANTICS was set to CHAR.

I don't see any other problem and any other difference. 

Does it really matter if even data in that column not having length of size specified at column level?.

is it the inconsistency in storage semantics or NLS settings that we should address in application ?. 
is it because of session nls parameters not compatible with nls database parameters or instance nls parameters ? this seems to make to believe the case YES. 

however more to come on this as when I found more on this. 

any comments and inputs or help is welcome. thanks.