[
https://issues.apache.org/jira/browse/DERBY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652641#action_12652641
]
stan edited comment on DERBY-728 at 12/3/08 9:33 AM:
--------------------------------------------------------------
Here's a possible workaround for this problem that bypasses DRDA compliance
issues. It's not elegant but makes it possible to address this issue without
changing the DRDA protocol. The idea is supporting database path aliases as a
property. This may have other benefits / uses as well. Your thoughts please.
Idea:
I know that some databases [maybe even DB2? DB2 uses DRDA and does not
encounter this problem] store location (host / port / path / name [or alias])
information in a file. Could we implement something similar (database
names/aliases) using derby properties that can be read by Network server from
the derby.properties file to resolve database names on the connection URL? For
the server-side you would only, I think, need to specify the absolute or
relative path to the database.
This seems innocuous enough a feature that we could backport to the older
codelines to resolve this issue? It would only impact existing implementations
that chose to set the property.
It struck me that something like what is done for the USER property might work
well:
derby.dbalias.myDbAlias=<Yada-Path>/realDbName
And the connection URL would list only 'myDbAlias'?? I guess this would have
to override derby.system.home and be overridded if the conneciton URL looked
like a PATH? There are probably other issues I have not thought of.
was (Author: stan):
This isn't the elegant but it seems to get around the problem and I
understand that it may not be possible to address this issue within the client
driver code without violating the DRDA standard. This idea (database aliases
as a property) may have other benefits / uses. Your thoughts please.
I know that some databases [maybe even DB2? DB2 uses DRDA and does not
encounter this problem] store location (host / port / path / name [or alias])
information in a file. Could we implement something similar (database
names/aliases) using derby properties that can be read by Network server from
the derby.properties file to resolve database names on the connection URL? For
the server-side you would only, I think, need to specify the absolute or
relative path to the database.
This seems innocuous enough a feature that we could backport to the older
codelines to resolve this issue? It would only impact existing implementations
that chose to set the property.
It struck me that something like what is done for the USER property might work
well:
derby.dbalias.myDbAlias=<Yada-Path>/realDbName
And the connection URL would list only 'myDbAlias'?? I guess this would have
to override derby.system.home and be overridded if the conneciton URL looked
like a PATH? There are probably other issues I have not thought of.
> Unable to create databases whose name containg Chinese characters through the
> client driver
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-728
> URL: https://issues.apache.org/jira/browse/DERBY-728
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.1.2.1
> Environment: Debian unstable, LInux 2.6.14.2, libc 2.3.5-6
> Reporter: Andrei Badea
>
> Trying to create a database with the following URL (note the Chinese
> character in the database name):
> jdbc:derby://localhost:1527/\u4e10;create=true
> throws the following exception:
> -----%<-----
> Exception in thread "main" org.apache.derby.client.am.SqlException: Unicode
> string can't convert to Ebcdic string
> at
> org.apache.derby.client.net.EbcdicCcsidManager.convertFromUCS2(Unknown Source)
> at
> org.apache.derby.client.net.Request.writeScalarPaddedString(Unknown Source)
> at
> org.apache.derby.client.net.NetConnectionRequest.buildRDBNAM(Unknown Source)
> at
> org.apache.derby.client.net.NetConnectionRequest.buildACCSEC(Unknown Source)
> at
> org.apache.derby.client.net.NetConnectionRequest.writeAccessSecurity(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
> at org.apache.derby.client.net.NetConnection.flowConnect(Unknown
> Source)
> at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at java.sql.DriverManager.getConnection(DriverManager.java:525)
> at java.sql.DriverManager.getConnection(DriverManager.java:193)
> at jdbctest.Main.main(Main.java:33)
> -----%<-----
> It's possible, however, to create databases using the embedded driver, using
> an URL like:
> jdbc:derby:\u4e10;create=true
> Tested with both 10.1.1.0 and 10.1.2.1 with the same result.
> Complete code to reproduce the bug:
> -----%<-----
> public static void main(String[] args) throws Exception {
> Class.forName("org.apache.derby.jdbc.ClientDriver");
> Connection conn =
> DriverManager.getConnection("jdbc:derby://localhost:1527/\u4e10;create=true");
> }
> -----%<-----
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
