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

Stephan van Loendersloot updated DERBY-3458:
--------------------------------------------

    Attachment: DERBY-3458_patch_2.stat
                DERBY-3458_patch_2.txt

The diff in patch_2 contains the function test for territory based databases. 
The original dblook_test.java has been slightly modified, to be able to extend 
it to the added dblook_test_territory.java.

I've only tested the 'derbytools' suite (and it runs without errors), because 
my test environment is somehow not setup properly to run 'derbyAll', which 
hangs on network server tests. This doesn't seem to be due to this patch, it 
also happens when I test on released versions. I need to look into that some 
more, but I'd appreciate it if someone else can verify that 'derbyAll' works.

Once I get my test environment right, I may add another function test which 
extends dblook_test_net.java, though for now, dblook works on our 
territory-based network servers (production).

> dblook fails on TERRITORY_BASED databases
> -----------------------------------------
>
>                 Key: DERBY-3458
>                 URL: https://issues.apache.org/jira/browse/DERBY-3458
>             Project: Derby
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 10.3.2.1
>            Reporter: Stephan van Loendersloot
>            Assignee: Stephan van Loendersloot
>            Priority: Minor
>             Fix For: 10.4.0.0
>
>         Attachments: DERBY-3458_patch_1.stat, DERBY-3458_patch_1.txt, 
> DERBY-3458_patch_2.stat, DERBY-3458_patch_2.txt
>
>
> I've created small patches for myself by replacing all related queries in the 
> 'tools' section with CASTs to CHARs and VARCHARs and would like to contribute 
> these to the community in case anyone else can confirm this is a bug.
> A small test case to reproduce the problem is provided below, the version of 
> Derby that provides the stacktrace is 10.3.2.1.
> Regards,
> Stephan van Loendersloot.
> Reproduction steps:
> ---------- 1: create_territory_db.sql  ----------
> CONNECT 
> 'jdbc:derby://localhost/dutch;user=dutch;password=dutch;create=true;territory=nl_NL;collation=TERRITORY_BASED';
> AUTOCOMMIT OFF;
> CREATE TABLE AIRLINES
>  (
>     AIRLINE CHAR(2) NOT NULL ,
>     AIRLINE_FULL VARCHAR(24),
>     BASIC_RATE DOUBLE PRECISION,
>     DISTANCE_DISCOUNT DOUBLE PRECISION,
>     BUSINESS_LEVEL_FACTOR DOUBLE PRECISION,
>     FIRSTCLASS_LEVEL_FACTOR DOUBLE PRECISION,
>     ECONOMY_SEATS INTEGER,
>     BUSINESS_SEATS INTEGER,
>     FIRSTCLASS_SEATS INTEGER
>  );
> COMMIT;
> DISCONNECT;
> EXIT;
> ---------- 2: use dbloook ----------
> dblook -d "jdbc:derby://localhost/dutch;user=dutch;password=dutch" -o 
> dutch.sql
> ---------- 3: stacktrace ----------
> java.sql.SQLSyntaxErrorException: Comparisons between 'CHAR (UCS_BASIC)' and 
> 'CHAR (TERRITORY_BASED)' are not supported. Types must be comparable. String 
> types must also have matching collation. If collation does not match, a 
> possible solution is to cast operands to force them to the default collation 
> (e.g. select tablename from sys.systables where CAST(tablename as 
> VARCHAR(128)) = 'T1')
>   at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
>   at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
>   at org.apache.derby.client.am.Statement.executeQuery(Unknown Source)
>   at org.apache.derby.tools.dblook.prepForDump(Unknown Source)
>   at org.apache.derby.tools.dblook.go(Unknown Source)
>   at org.apache.derby.tools.dblook.<init>(Unknown Source)
>   at org.apache.derby.tools.dblook.main(Unknown Source)
> Caused by: org.apache.derby.client.am.SqlException: Comparisons between 'CHAR 
> (UCS_BASIC)' and 'CHAR (TERRITORY_BASED)' are not supported. Types must be 
> comparable. String types must also have matching collation. If collation does 
> not match, a possible solution is to cast operands to force them to the 
> default collation (e.g. select tablename from sys.systables where 
> CAST(tablename as VARCHAR(128)) = 'T1')
>   at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
>   at org.apache.derby.client.net.NetStatementReply.parsePrepareError(Unknown 
> Source)
>   at 
> org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(Unknown 
> Source)
>   at 
> org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown
>  Source)
>   at 
> org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown 
> Source)
>   at 
> org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown 
> Source)
>   at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown 
> Source)
>   at org.apache.derby.client.am.Statement.flowExecute(Unknown Source)
>   at org.apache.derby.client.am.Statement.executeQueryX(Unknown Source)
>   ... 5 more
> -- **--> DEBUG: Comparisons between 'CHAR (UCS_BASIC)' and 'CHAR 
> (TERRITORY_BASED)' are not supported. Types must be comparable. String types 
> must also have matching collation. If collation does not match, a possible 
> solution is to cast operands to force them to the default collation (e.g. 
> select tablename from sys.systables where CAST(tablename as VARCHAR(128)) = 
> 'T1') 

-- 
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