Re: Derby and character set encodings
Thanks David for sending this. Let me note a few questions: 1. when one creates a new database, is the database created with a certain encoding that will be used ? And if so, is that encoding that of the locale I am in when I run the create database commands or is it utf-8 always ? (for example, for one of the Japanese locales of Solaris, the encoding of it is euc-jp) or could it be that of the encoding of the locale the actual dbase server is started in ? (which might be java's view of the users locale/encoding which would be I think the same as the OS locale user is in) I saw this from derby docs: "To support users in many different languages, Derby's SQL parser understands all Unicode characters and allows any Unicode character or number to be used in an identifier." but I don't know if it means that there is no concept of an encoding for a database itself or not. I think with Oracle for example, there is an argument to create database that lets one specify the encoding of it. 2. The locale the user is in when starting derby server - what things are affected by that - ie encoding of dbase, messages to user (if translated), time, date, etc ? (vs user needing to set separate variables or properties) 3. I think its allowed for identifiers like database names, table and column names, to have non ascii in them, if proper quoting is used when referring to them ? Thanks - Ken David Van Couvering wrote: Hi, all. I am getting some questions from Ken Frank NetBeans internationalization quality team about Java DB and character set encodings. Rather than try and play go-between, I'm including him here so he can directly ask any follow-on questions. Ken would like to understand how Derby makes use of character encodings, and how it is affected by various settings. How does Derby handle things if the encoding is set to something different from our default of UTF-8? Are we impacted, or do we rely on Java routines such as the Collator and Comparator class to handle this? Sorry if I'm talking out my ear, i18n is not one of my fortes. Thanks, David
Re: Derby and character set encodings
its the correct Andrey; he works with me on i18n; but also thanks for sending to Andrei also. Ken David Van Couvering wrote: I think this was actually meant to go to a different Andrei (sorry Andrey) On 9/6/07, David Van Couvering <[EMAIL PROTECTED]> wrote: I think I can actually answer some of these questions :) On 9/6/07, Ken Frank <[EMAIL PROTECTED]> wrote: Thanks David for sending this. Let me note a few questions: 1. when one creates a new database, is the database created with a certain encoding that will be used ? And if so, is that encoding that of the locale I am in when I run the create database commands or is it utf-8 always ? (for example, for one of the Japanese locales of Solaris, the encoding of it is euc-jp) or could it be that of the encoding of the locale the actual dbase server is started in ? (which might be java's view of the users locale/encoding which would be I think the same as the OS locale user is in) I saw this from derby docs: "To support users in many different languages, Derby's SQL parser understands all Unicode characters and allows any Unicode character or number to be used in an identifier." but I don't know if it means that there is no concept of an encoding for a database itself or not. I think with Oracle for example, there is an argument to create database that lets one specify the encoding of it. This question stumps me, I'll leave it to others... 2. The locale the user is in when starting derby server - what things are affected by that - ie encoding of dbase, messages to user (if translated), time, date, etc ? (vs user needing to set separate variables or properties) I don't know what "encoding of the dbase" means, but the other display stuff: exception messages, time and date and money formats, etc., are all controlled by locale. 3. I think its allowed for identifiers like database names, table and column names, to have non ascii in them, if proper quoting is used when referring to them ? Yes, that's right. Thanks - Ken David Van Couvering wrote: Hi, all. I am getting some questions from Ken Frank NetBeans internationalization quality team about Java DB and character set encodings. Rather than try and play go-between, I'm including him here so he can directly ask any follow-on questions. Ken would like to understand how Derby makes use of character encodings, and how it is affected by various settings. How does Derby handle things if the encoding is set to something different from our default of UTF-8? Are we impacted, or do we rely on Java routines such as the Collator and Comparator class to handle this? Sorry if I'm talking out my ear, i18n is not one of my fortes. Thanks, David
Re: ipv6 and Network Server hostname
In a round about fashion, we found out to use "::" (2 colons) in v6 for
0.0.0.0 (v4).
Now it is working fine.
NetworkServerControl serverControl = new
NetworkServerControl(InetAddress.getByName("::"),1527);
thanks much,
Dave Been
Enterprise Search Development
[EMAIL PROTECTED]
Phone 510-222-3926, Cell 928-699-0488
"Manjula Kutty" <[EMAIL PROTECTED]>
09/06/2007 12:38 PM
Please respond to
"Derby Discussion"
To
"Derby Discussion"
cc
Subject
Re: ipv6 and Network Server hostname
Hi Dave,
While doing some testing on the Ipv6 machines, I started the server as
java org.apache.derby.drda.NetworkServerControl start -h
2002:92a:8f7a:13:9:42:74:19
So instead of giving 0.0.0.0 I gave the full IP address. Did the same for
the localhost also. Hope I answered your question. If you need any more
information regarding derby on IPv6 please let me know.
Thanks,
Manjula.
On 9/6/07, Dave Been <[EMAIL PROTECTED]> wrote:
for IPv4 we listen on host 0.0.0.0 in case a machine has multiple NIC
cards, so we accept connections from all NICs.
(I believe this was for windows only. is that correct?)
Is there an equivelent ip for IPv6?
thanks
Dave Been
--
Thanks,
Manjula.
Re: Derby and character set encodings
I think this was actually meant to go to a different Andrei (sorry Andrey) On 9/6/07, David Van Couvering <[EMAIL PROTECTED]> wrote: > I think I can actually answer some of these questions :) > > On 9/6/07, Ken Frank <[EMAIL PROTECTED]> wrote: > > Thanks David for sending this. > > > > Let me note a few questions: > > > > 1. when one creates a new database, > > is the database created with a certain encoding that will be used ? > > > > And if so, is that encoding that of the locale I am in when I run > > the create database commands or is it utf-8 always ? > > (for example, for one of the Japanese locales of Solaris, the encoding of it > > is euc-jp) > > > > or could it be that of the encoding of the locale the actual dbase server > > is started in ? (which might be java's view of the users locale/encoding > > which would be I think the same as the OS locale user is in) > > > > I saw this from derby docs: > > "To support users in many different languages, Derby's SQL parser > > understands all Unicode characters and allows any Unicode character or > > number to be used in an identifier." > > > > but I don't know if it means that there is no concept of an encoding > > for a database itself or not. > > > > I think with Oracle for example, there is an argument to create database > > that lets one specify the encoding of it. > > > > This question stumps me, I'll leave it to others... > > > > > > > 2. The locale the user is in when starting derby server - > > what things are affected by that - ie encoding of dbase, messages to > > user (if translated), time, date, etc ? > > (vs user needing to set separate variables or properties) > > > > I don't know what "encoding of the dbase" means, but the other display > stuff: exception messages, time and date and money formats, etc., are > all controlled by locale. > > > 3. I think its allowed for identifiers like database names, > > table and column names, to have non ascii in them, if proper > > quoting is used when referring to them ? > > > > Yes, that's right. > > > > > Thanks - Ken > > > > > > David Van Couvering wrote: > > > > >Hi, all. I am getting some questions from Ken Frank NetBeans > > >internationalization quality team about Java DB and character set > > >encodings. Rather than try and play go-between, I'm including him > > >here so he can directly ask any follow-on questions. > > > > > >Ken would like to understand how Derby makes use of character > > >encodings, and how it is affected by various settings. How does > > >Derby handle things if the encoding is set to something different from > > >our default of UTF-8? Are we impacted, or do we rely on Java routines > > >such as the Collator and Comparator class to handle this? > > > > > >Sorry if I'm talking out my ear, i18n is not one of my fortes. > > > > > >Thanks, > > > > > >David > > > > > > > > >
Re: Derby and character set encodings
I think I can actually answer some of these questions :) On 9/6/07, Ken Frank <[EMAIL PROTECTED]> wrote: > Thanks David for sending this. > > Let me note a few questions: > > 1. when one creates a new database, > is the database created with a certain encoding that will be used ? > > And if so, is that encoding that of the locale I am in when I run > the create database commands or is it utf-8 always ? > (for example, for one of the Japanese locales of Solaris, the encoding of it > is euc-jp) > > or could it be that of the encoding of the locale the actual dbase server > is started in ? (which might be java's view of the users locale/encoding > which would be I think the same as the OS locale user is in) > > I saw this from derby docs: > "To support users in many different languages, Derby's SQL parser > understands all Unicode characters and allows any Unicode character or > number to be used in an identifier." > > but I don't know if it means that there is no concept of an encoding > for a database itself or not. > > I think with Oracle for example, there is an argument to create database > that lets one specify the encoding of it. > This question stumps me, I'll leave it to others... > > > 2. The locale the user is in when starting derby server - > what things are affected by that - ie encoding of dbase, messages to > user (if translated), time, date, etc ? > (vs user needing to set separate variables or properties) > I don't know what "encoding of the dbase" means, but the other display stuff: exception messages, time and date and money formats, etc., are all controlled by locale. > 3. I think its allowed for identifiers like database names, > table and column names, to have non ascii in them, if proper > quoting is used when referring to them ? > Yes, that's right. > > Thanks - Ken > > > David Van Couvering wrote: > > >Hi, all. I am getting some questions from Ken Frank NetBeans > >internationalization quality team about Java DB and character set > >encodings. Rather than try and play go-between, I'm including him > >here so he can directly ask any follow-on questions. > > > >Ken would like to understand how Derby makes use of character > >encodings, and how it is affected by various settings. How does > >Derby handle things if the encoding is set to something different from > >our default of UTF-8? Are we impacted, or do we rely on Java routines > >such as the Collator and Comparator class to handle this? > > > >Sorry if I'm talking out my ear, i18n is not one of my fortes. > > > >Thanks, > > > >David > > > > >
Re: ipv6 and Network Server hostname
Hi Dave, While doing some testing on the Ipv6 machines, I started the server as java org.apache.derby.drda.NetworkServerControl start -h 2002:92a:8f7a:13:9:42:74:19 So instead of giving 0.0.0.0 I gave the full IP address. Did the same for the localhost also. Hope I answered your question. If you need any more information regarding derby on IPv6 please let me know. Thanks, Manjula. On 9/6/07, Dave Been <[EMAIL PROTECTED]> wrote: > > > for IPv4 we listen on host 0.0.0.0 in case a machine has multiple NIC > cards, so we accept connections from all NICs. > (I believe this was for windows only. is that correct?) > > Is there an equivelent ip for IPv6? > > thanks > Dave Been -- Thanks, Manjula.
ipv6 and Network Server hostname
for IPv4 we listen on host 0.0.0.0 in case a machine has multiple NIC cards, so we accept connections from all NICs. (I believe this was for windows only. is that correct?) Is there an equivelent ip for IPv6? thanks Dave Been
Re: Derby and character set encodings
This is mixing a lot of things up. I also may use the wrong terminology here. Character set encodings really only come into play with tools like ij, and import getting the string from the environment into derby. The more standard interaction is using jdbc to load a java string into derby. At that level we don't do anything with encodings. We happen to use a modified utf8 to store stuff to disk, and this is not configurable. But no user interface should depend on this encoding, and Derby could change this storage in the future. Logically all strings at runtime are converted to standard java char. Before 10.3 we always used standard java string compare which did a numerical comparison of the unicode value of chars to arrive at ordering. That is still the default. In 10.3 an option was added to set the territory based collation when the database is created such that comparison is dependent on the territory of the database. For this standard java rule based Collator interfaces are used. This is documented in the latest derby release. David Van Couvering wrote: Hi, all. I am getting some questions from Ken Frank NetBeans internationalization quality team about Java DB and character set encodings. Rather than try and play go-between, I'm including him here so he can directly ask any follow-on questions. Ken would like to understand how Derby makes use of character encodings, and how it is affected by various settings. How does Derby handle things if the encoding is set to something different from our default of UTF-8? Are we impacted, or do we rely on Java routines such as the Collator and Comparator class to handle this? Sorry if I'm talking out my ear, i18n is not one of my fortes. Thanks, David
Derby and character set encodings
Hi, all. I am getting some questions from Ken Frank NetBeans internationalization quality team about Java DB and character set encodings. Rather than try and play go-between, I'm including him here so he can directly ask any follow-on questions. Ken would like to understand how Derby makes use of character encodings, and how it is affected by various settings. How does Derby handle things if the encoding is set to something different from our default of UTF-8? Are we impacted, or do we rely on Java routines such as the Collator and Comparator class to handle this? Sorry if I'm talking out my ear, i18n is not one of my fortes. Thanks, David
jdbc metadata getProcedures does not return newly created proc/funcs
latest Derby:
Apache Derby
10.3.1.4 - (561794)
Apache Derby Network Client JDBC Driver
10.1.2.1
I created 2 very simple stored proc/funcs:
package test;
import java.sql.SQLException;
public class SPHelper {
public static void ProcNoArgs() throws SQLException {
}
public static String FuncNoArgs() throws SQLException {
return "gidday";
}
}
CREATE PROCEDURE PROC_NO_ARGS()
LANGUAGE JAVA
EXTERNAL NAME 'test.SPHelper.ProcNoArgs'
PARAMETER STYLE JAVA
NO SQL;
CREATE FUNCTION FUNC_NO_ARGS() RETURNS VARCHAR(100)
LANGUAGE JAVA
EXTERNAL NAME 'test.SPHelper.FuncNoArgs'
PARAMETER STYLE JAVA
NO SQL
RETURNS NULL ON NULL INPUT;
Now, when I try to get the metadata for them, nothing is returned:
String catalogPattern = "";
String schemaPattern = "%";
String procedurePattern = "%NO_ARGS";
List tmpProcs
try {
DatabaseMetaData databaseMetaData = getDatabaseMetaData(connection);
procsInfo = databaseMetaData.getProcedures(catalogPattern,
schemaPattern, procedurePattern);
// did we get a hit?
if (procsInfo != null) {
tmpProcs = new ArrayList();
while (procsInfo.next()) {
String actualCatalogName = procsInfo.getString(PROCS_INFO_CATALOG);
//
index 1
String actualSchemaName = procsInfo.getString(PROCS_INFO_SCHEMA); //
index 2
String actualProcedureName = procsInfo.getString(PROCS_INFO_NAME);
//
index 3
short procedureType = procsInfo.getShort(PROCS_INFO_TYPE); // index
8
DbStoredProcedure dbStoredProcedure;
if (procedureType ==
java.sql.DatabaseMetaData.procedureReturnsResult)
{
dbStoredProcedure = new DbStoredFunction(actualProcedureName);
}
else {
dbStoredProcedure = new DbStoredProcedure(actualProcedureName);
}
if (actualCatalogName != null && actualCatalogName.length() > 0) {
dbStoredProcedure.setCatalog(actualCatalogName);
}
if (actualSchemaName != null && actualSchemaName.length() > 0) {
dbStoredProcedure.setSchema(actualSchemaName);
}
tmpProcs.add(dbStoredProcedure);
}
procsInfo.close();
}
catch (SQLException sqlException) {
throw new IllegalStateException("failure retrieving Stored Procedure
metadata",
sqlException);
}
No exceptions are thrown but the list is empty - an empty result set was
returned.
Any ideas?
Thanks in advance,
Mike
--
View this message in context:
http://www.nabble.com/jdbc-metadata-getProcedures-does-not-return-newly-created-proc-funcs-tf4392888.html#a12525073
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: cannot create a function with no arguments
that did it - thanks! Hi Mike, I think the problem is the datatype of the function's return value. The VARCHAR datatype needs a length. This should work: CREATE FUNCTION FUNC_NO_ARGS() RETURNS VARCHAR( 100 ) ... Hope this helps, -Rick -- View this message in context: http://www.nabble.com/cannot-create-a-function-with-no-arguments-tf4392364.html#a12524824 Sent from the Apache Derby Users mailing list archive at Nabble.com.
Derby 10.3.1.4 not working with ibatis-2.3.0.677
Hi, I tried to upgrade to derby 10.3.1.4 but I get strange error messages that I didn't get with derby 10.2.2.0. I use 10.3.1.4 with ibatis-2.3.0.677. Any ideas? Zsolt com.intland.codebeamer.persistence.util.PersistenceException: com.ibatis.common.jdbc.exception.NestedSQLException: --- The error occurred in com/intland/codebeamer/persistence/dao/sqlmap/UserDao.xml. --- The error occurred while applying a parameter map. --- Check the createUser-InlineParameterMap. --- Check the parameter mapping for the 'hostName' property. --- Cause: java.sql.SQLException: An attempt was made to get a data value of type '' from a data value of type 'VARCHAR'. at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeUpdate(Ge neralStatement.java:91) at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.insert(SqlMapExecutorDe legate.java:447) at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.insert(SqlMapSessionImpl.jav a:82) at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.insert(SqlMapClientImpl.java: 59) at com.intland.codebeamer.persistence.util.SqlMapClientWrapper.insert(SqlMapCli entWrapper.java:298) at com.intland.codebeamer.persistence.dao.AbstractDao.create(AbstractDao.java:8 1) at com.intland.codebeamer.persistence.dao.impl.UserDaoImpl.create(UserDaoImpl.j ava:81) at com.intland.codebeamer.persistence.test.WorkingSetItemDaoTests.prepareDummy( WorkingSetItemDaoTests.java:72) at com.intland.codebeamer.persistence.test.WorkingSetItemDaoTests.testCrud(Work ingSetItemDaoTests.java:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.springframework.test.ConditionalTestCase.runBare(ConditionalTestCase.jav a:69) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T estReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3 8) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu nner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu nner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner. java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner .java:196) Caused by: com.ibatis.common.jdbc.exception.NestedSQLException: --- The error occurred in com/intland/codebeamer/persistence/dao/sqlmap/UserDao.xml. --- The error occurred while applying a parameter map. --- Check the createUser-InlineParameterMap. --- Check the parameter mapping for the 'hostName' property. --- Cause: java.sql.SQLException: An attempt was made to get a data value of type '' from a data value of type 'VARCHAR'. ... 26 more Caused by: java.sql.SQLException: An attempt was made to get a data value of type '' from a data value of type 'VARCHAR'. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.PreparedStatement.setNull(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.ibatis.common.jdbc.logging.PreparedStatementLogProxy.invoke(PreparedStat ementLogProxy.java:70) at $Proxy1.setNull(Unknown Source) at com.ibatis.sqlmap.engine.mapping.parameter.BasicParameterMap.setParameter(Ba sicParameterMap.java:171) at com.ibatis.sqlmap.engine.mapping.parameter.BasicParameterMap.setParameters(B asicParameterMap.java:125) at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeUpdate(SqlExecutor.jav a:79) at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecuteUpdate (GeneralStatement.java:200) at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeUpdate(Ge neralStatement.java:78) ... 25 more Caused by: org.apache.derby.client.am.SqlException: An attempt was made to get a data value of type '' from
Re: cannot create a function with no arguments
Hi Mike,
I think the problem is the datatype of the function's return value. The
VARCHAR datatype needs a length. This should work:
CREATE FUNCTION FUNC_NO_ARGS() RETURNS VARCHAR( 100 )
...
Hope this helps,
-Rick
Mike Norman wrote:
latest Derby:
Apache Derby
10.3.1.4 - (561794)
Apache Derby Network Client JDBC Driver
10.1.2.1
I have an extremely simple helper class:
package test;
import java.sql.SQLException;
public class SPHelper {
public static void ProcNoArgs() throws SQLException {
}
public static String FuncNoArgs() throws SQLException {
return "gidday";
}
}
The first external procedure works:
CREATE PROCEDURE PROC_NO_ARGS()
LANGUAGE JAVA
EXTERNAL NAME 'test.SPHelper.ProcNoArgs'
PARAMETER STYLE JAVA
NO SQL
but I cannot create a no-arg function:
CREATE FUNCTION FUNC_NO_ARGS() RETURNS VARCHAR
LANGUAGE JAVA
EXTERNAL NAME 'test.SPHelper.FuncNoArgs'
PARAMETER STYLE JAVA
NO SQL
CALLED ON NULL INPUT
I get the following exception:
09:43:30 [CREATE - 0 row(s), 0.000 secs] [Error Code: -1, SQL State:
42X01] Syntax error: Encountered "LANGUAGE" at line 2, column 3.
... 1 statement(s) executed, 0 row(s) affected, exec/fetch time: 0.000/0.000
sec [0 successful, 0 warnings, 1 errors]
Any ideas?
cannot create a function with no arguments
latest Derby:
Apache Derby
10.3.1.4 - (561794)
Apache Derby Network Client JDBC Driver
10.1.2.1
I have an extremely simple helper class:
package test;
import java.sql.SQLException;
public class SPHelper {
public static void ProcNoArgs() throws SQLException {
}
public static String FuncNoArgs() throws SQLException {
return "gidday";
}
}
The first external procedure works:
CREATE PROCEDURE PROC_NO_ARGS()
LANGUAGE JAVA
EXTERNAL NAME 'test.SPHelper.ProcNoArgs'
PARAMETER STYLE JAVA
NO SQL
but I cannot create a no-arg function:
CREATE FUNCTION FUNC_NO_ARGS() RETURNS VARCHAR
LANGUAGE JAVA
EXTERNAL NAME 'test.SPHelper.FuncNoArgs'
PARAMETER STYLE JAVA
NO SQL
CALLED ON NULL INPUT
I get the following exception:
09:43:30 [CREATE - 0 row(s), 0.000 secs] [Error Code: -1, SQL State:
42X01] Syntax error: Encountered "LANGUAGE" at line 2, column 3.
... 1 statement(s) executed, 0 row(s) affected, exec/fetch time: 0.000/0.000
sec [0 successful, 0 warnings, 1 errors]
Any ideas?
--
View this message in context:
http://www.nabble.com/cannot-create-a-function-with-no-arguments-tf4392364.html#a12523237
Sent from the Apache Derby Users mailing list archive at Nabble.com.
