[ 
https://issues.apache.org/jira/browse/DERBY-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499849
 ] 

A B commented on DERBY-2703:
----------------------------

> Since this is a system catalog query I am surprised the result is affected at 
> all by collation, so
> there may be a derby bug in the metadata routines, or elsewhere. 

The metadata queries all have parameters (see metadata.properties) and are 
prepared via PreparedStatements (see EmbedDatabaseMetaData.java).  Since 
parameters always take the collation of the schema in which they are prepared, 
I wonder if the params are assuming territory-based collation?  If so, then 
comparison with a field from the system catalogs may not work as expected.  It 
seems like we should be throwing an error in that case (UCS vs territory 
comparison), but maybe something's going on under the covers that is 
masking/avoiding the error...?

If you set the current schema to SYS before executing the getColumns() call, 
does that change anything?  Just a guess...I haven't actually done any 
investigation...

> calling DatabaseMetaData.getColumns() with % for matching column character in 
> a territory based collated db does not work in 1.4.2 jvms
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2703
>                 URL: https://issues.apache.org/jira/browse/DERBY-2703
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.3.0.0
>         Environment: have reproduced on ibm142 and sun142 jvms
>            Reporter: Mike Matrigali
>
> calling DatabaseMetaData.getColumns(null, "APP", "CUSTOMER", "%") returns no 
> rows for a valid APP.CUSTOMER table
> in ibm142 and sun142 jvms, for databases created with territory based 
> collation, fails in all 3 cases we test in the 
> CollationTest2.java junit test.
> Since this is a system catalog query I am surprised the result is affected at 
> all by collation, so there may be a derby bug 
> in the metadata routines, or elsewhere.  Mamta, could you comment if you 
> believe this should work already - or if there
> is more work to do in this area.
> I will soon checkin a test case into the CollationTest2.java unit test that 
> shows this.  For now I will either comment out the
> entire test, or if I can figure out how to not run it on 142 I will do that.

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