[ 
https://issues.apache.org/jira/browse/DERBY-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel John Debrunner updated DERBY-2618:
-----------------------------------------

    Attachment: derby2618_partial_v2.txt

Improved patch which attempts to fix ClobStreamControl.getStreamPosition() 
handling of formatted UTF8 data.

Still does not fix the problems seen with the repro because ClobStreamControl 
has various errors with its handling of positions.

One potential fix was made in ClobStreamControl.getWriter (long pos).

The old code had:

 long charPos = getStreamPosition (0, pos);

but getStreamPosition() is defined as returning a *byte* position for a 
character position, so the name of the variable is confusing.

Possibly due to this confusion then code then subsequently did:

 new ClobUtf8Writer (this, getStreamPosition (0, charPos))

thus the *byte* position was converted into a byte position again, which is 
bound to cause problems.

The change has renamed the variable to bytePos and passed in directly into new 
ClobUtf8Writer.

There are still issues with the code in ClobStreamControl but I'll put those in 
a different comment.

> EmbedClob.setAsciiStream does not handle non-ascii characters correctly
> -----------------------------------------------------------------------
>
>                 Key: DERBY-2618
>                 URL: https://issues.apache.org/jira/browse/DERBY-2618
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.3.0.0
>            Reporter: Kristian Waagan
>         Assigned To: Daniel John Debrunner
>         Attachments: derby2618_partial_v1.txt, derby2618_partial_v2.txt, 
> Derby2618BugsInClobAsciiStream.java
>
>
> If non-ascii characters are written to the Writer returned by 
> EmbedClob.setAsciiStream, Derby fails with a 'java.io.UTFDataFormatException' 
> when the CLOB value is read back.
> I'm filing this bug with 'Major' priority, as the bug does not manifest 
> itself when entering data, just when you try to get it back. Except from 
> filtering the data yourself before entering it, I don't think there is any 
> workaround.
> Sample stack trace from a modified test:
> 1) 
> testClobAsciiWrite1ParamKRISTIWAA(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)java.sql.SQLException:
>  Unable to set stream: 'java.io.UTFDataFormatException'.
>         at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
>         at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88)
>         at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:94)
>         at org.apache.derby.impl.jdbc.Util.setStreamFailure(Util.java:246)
>         at org.apache.derby.impl.jdbc.EmbedClob.length(EmbedClob.java:190)
>         at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.setClob(EmbedPreparedStatement.java:1441)
>         at 
> org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest.testClobAsciiWrite1ParamKRISTIWAA(LobStreamsTest.java:255)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at 
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88)
> Caused by: java.sql.SQLException: Unable to set stream: 
> 'java.io.UTFDataFormatException'.
>         at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
>         at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:135)
>         at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
>         ... 22 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to