You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <de...@db.apache.org> on 2006/05/01 19:02:47 UTC
[jira] Commented: (DERBY-1264) importExportThruIJ.sql supportfiles
sqlAnywhere* need to be copied in fixed encoding
[ http://issues.apache.org/jira/browse/DERBY-1264?page=comments#action_12377247 ]
Myrna van Lunteren commented on DERBY-1264:
-------------------------------------------
Yes, I do need this on 10.1
I tried to merge, but it gave me this: 'svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: cannot replace a directory from within'....
Any suggestions?
> importExportThruIJ.sql supportfiles sqlAnywhere* need to be copied in fixed encoding
> ------------------------------------------------------------------------------------
>
> Key: DERBY-1264
> URL: http://issues.apache.org/jira/browse/DERBY-1264
> Project: Derby
> Type: Test
> Components: Test
> Versions: 10.2.0.0
> Environment: zOS/ OS/390
> Reporter: Myrna van Lunteren
> Assignee: Myrna van Lunteren
> Priority: Trivial
> Attachments: DERBY-1264_102_20060428.diff, DERBY-1264_102_20060428.stat
>
> The test tools/importExportThruIJ.sql fails after the changes for DERBY-658, because the harness now tries to copy the supportfiles testData/importExport/sqlAnywhere1.txt and sqlAnywhere2.txt into local encoding.. This gives the following error:
> Exception in thread "main" sun.io.MalformedInputException
> at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:278)
> Note: before, DERBY-658, these 2 files would have to be *not* run through native2ascii. The test explicitly assumes the contents to be ASCII (that is, the import indicates "ASCII"). My notes indicate that with 10.1.1, this test then passed with ibm14.
> Because the copying is done based on extension, these two files need to be renamed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1264) importExportThruIJ.sql supportfiles
sqlAnywhere* need to be copied in fixed encoding
Posted by Mike Matrigali <mi...@sbcglobal.net>.
i got a similar error on one my merges. In that case the svn number
was from when we were incubator vs. graduated. I am not exactly sure
what range of svn number was the cutoff. So for merge I had to
use something like:
svn merge -r 219206:219207
https://svn.apache.org/repos/asf/incubator/derby/code/trunk/ .
Myrna van Lunteren (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1264?page=comments#action_12377247 ]
>
> Myrna van Lunteren commented on DERBY-1264:
> -------------------------------------------
>
> Yes, I do need this on 10.1
>
> I tried to merge, but it gave me this: 'svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: cannot replace a directory from within'....
>
> Any suggestions?
>
>
>>importExportThruIJ.sql supportfiles sqlAnywhere* need to be copied in fixed encoding
>>------------------------------------------------------------------------------------
>>
>> Key: DERBY-1264
>> URL: http://issues.apache.org/jira/browse/DERBY-1264
>> Project: Derby
>> Type: Test
>
>
>> Components: Test
>> Versions: 10.2.0.0
>> Environment: zOS/ OS/390
>> Reporter: Myrna van Lunteren
>> Assignee: Myrna van Lunteren
>> Priority: Trivial
>> Attachments: DERBY-1264_102_20060428.diff, DERBY-1264_102_20060428.stat
>>
>>The test tools/importExportThruIJ.sql fails after the changes for DERBY-658, because the harness now tries to copy the supportfiles testData/importExport/sqlAnywhere1.txt and sqlAnywhere2.txt into local encoding.. This gives the following error:
>>Exception in thread "main" sun.io.MalformedInputException
>> at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:278)
>>Note: before, DERBY-658, these 2 files would have to be *not* run through native2ascii. The test explicitly assumes the contents to be ASCII (that is, the import indicates "ASCII"). My notes indicate that with 10.1.1, this test then passed with ibm14.
>>Because the copying is done based on extension, these two files need to be renamed.
>
>