[ https://issues.apache.org/jira/browse/OPENJPA-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162388#comment-13162388 ] 

Karl PIhlblad commented on OPENJPA-2086:
----------------------------------------

After some investigation, it seems as if the nchar information is gathered from the @Column( columnDefintion ) attribute.

 However, The documentation states that the attribute "is only used by vendors that support creating tables from your mapping metadata.",
 and nothing is mentioned in the OracleDictionary properties section.

 Regarding setFixedChar; The type information doesn't seem to be available for dynamic columns,
 as the type seems to be set from a "template" VARCHAR(255).  I suppose it means "a big string" :-)
                
> OracleDictionary  setFixed and setFormOfUse(NCLOB) are not really doing what they should.
> -----------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-2086
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2086
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc
>    Affects Versions: 2.1.1, 2.2.0
>         Environment: Oracle 9g, 10g and 11g
>            Reporter: Karl PIhlblad
>            Priority: Minor
>              Labels: charset, nchar, openjpa, oracle
>
> The setString() method in the OracleDictionary tries to be smart and and look up the column type, and detect and apply nchar and/or fixed char semantics.
> However, I believe that the type information is normally not present for queries, and the functions are never called.
> That means that characters outside the database character set will be lost during translation, and that comparison on CHAR (fixed length) columns will not match if 
> the arguments are not padded to the column length.
>  
> I suggest that the special nchar handling is removed as it is not working properly. The only "reliable" option is to set the connection property oracle.jdbc.defaultNChar=true,
> as it would be neigh impossible to get this right in an automatic way.
> (Actually, the sensible option is to convert the database to AL32UTF8, and not use nchars at all since Oracles nchar handling seems to be problematic. )
> Further as the fixedString handling also does not work without type information, the dictionary could either always, or depending on a flag,  
> call the setFixedChar() method, or just rely on the connection parameter "fixedString" (and use setObject), avoiding the complexity (and the cost of reflection calls)  altogether.
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira