Doubts about encoding, using the database across different OS/encoding
Hi, I have some doubts about encoding, I am not an expert about encodings so I prefer to ask. Let's say I create and use the database on a Windows pc (so encoding is like Windows-1252 but not UTF-8, and the application is running with default OS encoding), I store some text data in tables etc. then I move and use the database on a linux pc that has encoding UTF-8 and the application will still run with default OS encoding. Can this cause problems with text data? Can the data stored when I was using the database on Windows read wrong on the Linux system (and vice versa if I move the db again) ? Thanks for the help - fed
Re: disable creations of new databases when running the network server
Hi Rick, thanks for the answer, I know it seems an obvious question but what do you mean with "valid user" ? I try to explain: my setup is this one (I asked help for it time ago in the mailing list): a dbs/ dir (that is derby.system.home) where I have all of my db (db1, db2, db3 etc) every one with their own native authentication and a credentials db used by the network server, with derby,properties that is derby.authentication.provider=NATIVE:credentials the valid users that can create a new db are the one defined in the credentials db, right? Thanks for the help. - fed On Sat, 16 Sept 2023 at 20:04, Rick Hillegas wrote: > You are correct. Any valid user can create as many databases as they > want, provided that the databases are created in a part of the file > system which is write-accessible to the engine jar and to the account > which runs the server. There is no way to prevent a valid user from > creating databases. > > On 9/15/23 11:51 PM, fed wrote: > > Hi, > > > > My doubt is that, if I am not wrong, every user that can connect to the > > network server can create a new database and so indirectly a new > directory > > in the same places where the user that runs the network server have write > > permissions. > > I would prefer to create the database not directly on the network server > > but with the embedded driver and then later make it available on the > > network server. > > Maybe it is possible to limit this behaviour via the security manager > but I > > don't think this can change a lot of the behaviour. > > > > Is it possible to disable/prevent/limit this? > > > > Thanks for the help > > - fed > > > >
disable creations of new databases when running the network server
Hi, My doubt is that, if I am not wrong, every user that can connect to the network server can create a new database and so indirectly a new directory in the same places where the user that runs the network server have write permissions. I would prefer to create the database not directly on the network server but with the embedded driver and then later make it available on the network server. Maybe it is possible to limit this behaviour via the security manager but I don't think this can change a lot of the behaviour. Is it possible to disable/prevent/limit this? Thanks for the help - fed
Doubts about online backups using freeze / unfreeze
Hi,
I have a derby network server running with some databases connected and I
want to backup the databases directory with my backup utility.
My idea is to connect to every database in the network server and call the
freeze procedure, execute the backup of the databases directories and then
call the unfreeze procedure on every db, but I have some doubts.
Q1:
I am going for every database to get a connection, execute
CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE()
and then close the connection. After this I execute the backup with my
backup utility and then later after the backup is finished for every
database get a new connection and execute:
CALL SYSCS_UTIL.SYSCS_UNFREEZE_DATABASE() , is this correct?
>From the example in the documentation it seems that I have to use the same
connection to call the two stored procedures, but this is not required,
right?
public static void backUpDatabaseWithFreeze(Connection conn)
throws SQLException {
Statement s = conn.createStatement();
s.executeUpdate(
"CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE()");
*//copy the database directory during this interval*
s.executeUpdate(
"CALL SYSCS_UTIL.SYSCS_UNFREEZE_DATABASE()");
s.close();
}
Q2:
If I stop the network server while the database is in "freeze" state when I
restart it, it is still in "freeze" state and I have to call unfreeze on it?
My concern is that It is not possible that I get stuck in the "freeze"
state of the database, I can always "unfreeze" it, right?
Q3:
Last question, sorry for lots of questions: just to confirm even if in a
freeze state I can acquire a connection and execute a read operation
(select) on the database even in a transaction, right?
Thanks for the help
- fed
Re: Network server with different java (or derby) version between client and server
Hi,
Sorry for the late reply to this mail but I was able to create and test a
configuration and I have some doubts and questions.
I ask you if you can review my config that I describe in the mail.
I am sorry if it is a long email, I hope someone will read it :)
In my test environment I have the directory with databases in /tmp/1/ and
as derby installation directory /tmp/2/ so I have
/tmp/2/db-derby-10.15.2.0-bin/lib.
I put my databases in /tmp/1 so I have /tmp/1/db1 , /tmp/1/db2 etc. and I
created in the same dir a new database named credentials where I enabled
native authentication that will be used by the network server for shutdown
with user/password.
I created /tmp/1/derby.properties file with content:
derby.authentication.provider=NATIVE:credentials
I edited the server template that comes from the templates dir in the demo
dir (I paste it at the end of the email) and I put it
/tmp/2/db-derby-10.15.2.0-bin/lib.
To run the server I use, from /tmp/2/db-derby-10.15.2.0-bin/lib :
java -Djava.security.policy=serverTemplate.policy
-Dderby.system.home=/tmp/1 -jar derbyrun.jar server start
Every database in /tmp/1 has native authentication enabled, so every
database has its own user/password different for each one.
It seems to work: I can connect to the various databases and to shutdown
the server I have to use
java -jar derbyrun.jar server shutdown -user someuser -password somepassword
where someuser and somepassword are the ones that I defined in the
credentials database.
Is my test environment/configuration correct ?
I have other questions:
1 - it’s not clear to me how credentials db used by the server affects the
creation of new databases. I see that to create a database I have to use
the same credentials I saved in the credentials database, but if I have a
database just created, so not new, with its owner defined this will not
affect this database, right? Also It’s not clear if I have to use
derby.authentication.provider=NATIVE:credentials or
derby.authentication.provider=NATIVE:credentials:LOCAL for server
credentials in /tmp/1/derby.properties.
This can be ok, what I would like is to disable or make passwords protect
the creation of databases on the server but in most cases I will use
databases that I created before I put them on the server, with their
user/password so if this is how it works for me is ok.
2 - Does the shutdown of the server imply the shutdown of every database ?
Is it enough ? I don’t have to call shutdown to every database individually
I suppose.
Thanks for the help, I copy my server policy file where I just substituted
${derby.install.url} with file:///tmp/2/db-derby-10.15.2.0-bin/lib/.
-Fed
// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements. See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License. You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
grant codeBase "file:///tmp/2/db-derby-10.15.2.0-bin/lib/derbyshared.jar"
{
// Needed to determine whether the JVM was booted with a module path.
permission java.util.PropertyPermission "jdk.module.path", "read";
// Need in order to read message localizations from other derby jars
// when running with a module path.
permission java.io.FilePermission "${derby.install.path}${/}-", "read";
// Gives permission for JMX to be used against Derby
// but only if JMX authentication is not being used.
// In that case the application would need to create
// a whole set of fine-grained permissions to allow specific
// users access to MBeans and actions they perform.
permission org.apache.derby.shared.common.security.SystemPermission
"engine", "monitor";
permission org.apache.derby.shared.common.security.SystemPermission
"server", "monitor";
};
grant codeBase "file:///tmp/2/db-derby-10.15.2.0-bin/lib/derby.jar"
{
// These permissions are needed for everyday, embedded Derby usage.
permission java.lang.RuntimePermission "createClassLoader";
permission java.util.PropertyPermission "derby.*", "read";
permission java.util.PropertyPermission "user.dir", "read";
permission org.apache.derby.shared.common.security.SystemPermission
"engine", "usederbyinternals";
permission java.io.File
Re: Network server with different java (or derby) version between client and server
Another thing I don't understand is about shutdown, from the documentation,
adminguide, it says:
https://db.apache.org/derby/docs/10.15/adminguide/tadminconfigshuttingdownthenetworkserver.html
"Important: If user authentication is enabled, you must specify a valid
Derby user name and password; if the user authentication check fails,
you'll see an authentication error and the running server remains intact.
Note that Derby does not yet restrict the shutdown privilege to specific
users: the server can be shut down by any user on the server machine who
presents valid credentials."
Which username and password ?
from a single network server running I can access multiple databases,
right?
Considering jdbc url I can access them in this way I suppose for example:
`jdbc:derby://localhost:1527/db/db1`
`jdbc:derby://localhost:1527/db/db2
... etc`
if every one of them will have their own user/password (I am using NATIVE
authentication) so what password has to be specified on shutdown ?
And testing it seems I can shutdown it even without providing any
user/password.
Thanks for the help.
On Thu, 1 Dec 2022 at 13:15, fed wrote:
> Hi,
>
> As you suggested, the issue is the security manager, to be honest I am
> used to java security manager, I read and tested a bit to understand how it
> works.
> My initial setup was server service in a dir, let’s say /dir1 and database
> in another dir let’s say /dir2 so the dirs are distinct to each other.
>
> Considering version 10.15.2.0 running the server without security manager
> works:
>
> java -jar derbyrun.jar server -noSecurityManager start
>
> but reading from documentation I know it is not recommended and advisable
> so I want to use the security manager.
>
> So then I put my db dir inside the lib dir where derbyrun.jar and other
> jars are, so something like lib/db/mydb and running it with
> java -jar derbyrun.jar server start
> and I can access the db even using relative path on jdbc url, db/mydb.
>
> I am not used to derby in server mode, I read the documentation but sorry
> it’s not all clear to me how to use it.
> So from my test I suppose the recommended setup is to create a db dir
> inside lib and put all the dbs inside it ? lib/db/db1, lib/db/db2 etc ?
> right?
>
> Just as note I tested again with 10.12.1.1 and I found that forcing the
> security policy with the server template one (I suppose the default
> behaviour is changed with the newer version) it behaves the same like
> 10.15.2.0, I used:
> java
> -Djava.security.policy=/tmp/db-derby-10.12.1.1-bin/demo/templates/server.policy
> -jar derbyrun server start
>
> Thanks for the help.
>
> On Fri, 25 Nov 2022 at 21:02, Rick Hillegas
> wrote:
>
>> Check that your 10.15 classpath is correct. You need a couple more jar
>> files compared to previous releases. Your 10.15 server classpath must
>> contain the following jars:
>>
>>derby.jar
>>derbyshared.jar
>>derbytools.jar
>>derbynet.jar
>>
>> See
>>
>> https://db.apache.org/derby/docs/10.15/adminguide/tadminappschangingyourclasspath.html
>> and
>>
>> https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.server/module-summary.html
>>
>>
>> On 11/25/22 9:51 AM, Rick Hillegas wrote:
>> > This indicates that the server is running with a Java SecurityManager
>> > and that the policy file does not grant read permission on that
>> > file--and probably all files in the database directory.
>> >
>> > On 11/25/22 12:30 AM, fed wrote:
>> >> Hi,
>> >>
>> >> testing with 10.15.2.0 from derby.log, server side, it complains about
>> a
>> >> read permission on service.properties, some part of the file:
>> >>
>> >> java.sql.SQLException: Impossibile avviare il database
>> >> '/home/user/db/' con
>> >> il caricatore di classi
>> >> jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc. Per i
>> >> dettagli,
>> >> vedere l'eccezione successiva.
>> >> ...
>> >> Caused by: java.security.AccessControlException: access denied
>> >> ("java.io.FilePermission" "/home/user/db/service.properties" "read")
>> >> ...
>> >> ERROR XBM0C: Privilegio mancante per l'operazione 'exists' sul file
>> >> 'service.properties': access denied ("java.io.FilePermission"
>> >> "/home/user/db/service.properties" "read")
>> >>
>> >>
>> >> There are several errors like these ones but I have read permission
>> >> on t
Re: Network server with different java (or derby) version between client and server
Hi,
As you suggested, the issue is the security manager, to be honest I am used
to java security manager, I read and tested a bit to understand how it
works.
My initial setup was server service in a dir, let’s say /dir1 and database
in another dir let’s say /dir2 so the dirs are distinct to each other.
Considering version 10.15.2.0 running the server without security manager
works:
java -jar derbyrun.jar server -noSecurityManager start
but reading from documentation I know it is not recommended and advisable
so I want to use the security manager.
So then I put my db dir inside the lib dir where derbyrun.jar and other
jars are, so something like lib/db/mydb and running it with
java -jar derbyrun.jar server start
and I can access the db even using relative path on jdbc url, db/mydb.
I am not used to derby in server mode, I read the documentation but sorry
it’s not all clear to me how to use it.
So from my test I suppose the recommended setup is to create a db dir
inside lib and put all the dbs inside it ? lib/db/db1, lib/db/db2 etc ?
right?
Just as note I tested again with 10.12.1.1 and I found that forcing the
security policy with the server template one (I suppose the default
behaviour is changed with the newer version) it behaves the same like
10.15.2.0, I used:
java
-Djava.security.policy=/tmp/db-derby-10.12.1.1-bin/demo/templates/server.policy
-jar derbyrun server start
Thanks for the help.
On Fri, 25 Nov 2022 at 21:02, Rick Hillegas wrote:
> Check that your 10.15 classpath is correct. You need a couple more jar
> files compared to previous releases. Your 10.15 server classpath must
> contain the following jars:
>
>derby.jar
>derbyshared.jar
>derbytools.jar
>derbynet.jar
>
> See
>
> https://db.apache.org/derby/docs/10.15/adminguide/tadminappschangingyourclasspath.html
> and
>
> https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.server/module-summary.html
>
>
> On 11/25/22 9:51 AM, Rick Hillegas wrote:
> > This indicates that the server is running with a Java SecurityManager
> > and that the policy file does not grant read permission on that
> > file--and probably all files in the database directory.
> >
> > On 11/25/22 12:30 AM, fed wrote:
> >> Hi,
> >>
> >> testing with 10.15.2.0 from derby.log, server side, it complains about a
> >> read permission on service.properties, some part of the file:
> >>
> >> java.sql.SQLException: Impossibile avviare il database
> >> '/home/user/db/' con
> >> il caricatore di classi
> >> jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc. Per i
> >> dettagli,
> >> vedere l'eccezione successiva.
> >> ...
> >> Caused by: java.security.AccessControlException: access denied
> >> ("java.io.FilePermission" "/home/user/db/service.properties" "read")
> >> ...
> >> ERROR XBM0C: Privilegio mancante per l'operazione 'exists' sul file
> >> 'service.properties': access denied ("java.io.FilePermission"
> >> "/home/user/db/service.properties" "read")
> >>
> >>
> >> There are several errors like these ones but I have read permission
> >> on this
> >> file.
> >> The user that starts the server is the same that owns the file, the
> >> permissions on the file are 664.
> >>
> >> As I said, same setup but using 10.12.1.1 for the server, I have no
> >> problems.
> >>
> >> Best Regards
> >> -fed
> >>
> >> On Thu, 24 Nov 2022 at 19:52, Rick Hillegas
> >> wrote:
> >>
> >>> The SQLState indicates that the server was not able to boot the
> >>> database. Look in the server-side derby.log to see if there is a
> >>> detailed error message describing why the boot failed.
> >>>
> >>> On 11/23/22 4:42 PM, fed wrote:
> >>>> Hi,
> >>>>
> >>>> Sorry for the late answer but I lost your reply.
> >>>>
> >>>> Two tests:
> >>>>
> >>>> I have a database updated to version 10.12.1.1, the server is running
> >>> with
> >>>> the 10.12.1.1 too and the client is using 10.12.1.1 too, the
> >>>> connection
> >>> is
> >>>> OK, I can use this setup.
> >>>>
> >>>> But another test:
> >>>> still the same database updated to version 10.12.1.1, the server is
> >>> running
> >>>> 10.15.2.0 so a newer version and the client is using 10.12.1.1: I
> have
> >>>> problems
Re: Network server with different java (or derby) version between client and server
Hi,
testing with 10.15.2.0 from derby.log, server side, it complains about a
read permission on service.properties, some part of the file:
java.sql.SQLException: Impossibile avviare il database '/home/user/db/' con
il caricatore di classi
jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc. Per i dettagli,
vedere l'eccezione successiva.
...
Caused by: java.security.AccessControlException: access denied
("java.io.FilePermission" "/home/user/db/service.properties" "read")
...
ERROR XBM0C: Privilegio mancante per l'operazione 'exists' sul file
'service.properties': access denied ("java.io.FilePermission"
"/home/user/db/service.properties" "read")
There are several errors like these ones but I have read permission on this
file.
The user that starts the server is the same that owns the file, the
permissions on the file are 664.
As I said, same setup but using 10.12.1.1 for the server, I have no
problems.
Best Regards
-fed
On Thu, 24 Nov 2022 at 19:52, Rick Hillegas wrote:
> The SQLState indicates that the server was not able to boot the
> database. Look in the server-side derby.log to see if there is a
> detailed error message describing why the boot failed.
>
> On 11/23/22 4:42 PM, fed wrote:
> > Hi,
> >
> > Sorry for the late answer but I lost your reply.
> >
> > Two tests:
> >
> > I have a database updated to version 10.12.1.1, the server is running
> with
> > the 10.12.1.1 too and the client is using 10.12.1.1 too, the connection
> is
> > OK, I can use this setup.
> >
> > But another test:
> > still the same database updated to version 10.12.1.1, the server is
> running
> > 10.15.2.0 so a newer version and the client is using 10.12.1.1: I have
> > problems in this case the client can't connect to the database with this
> > error:
> >
> > Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error:
> > ERRORCODE: 4, SQLSTATE: XJ040, SQLERRMC: Impossibile avviare il
> > database '/home/user/some_db_path/' con il caricatore di classi
> > jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc. Per i
> dettagli,
> > vedere l'eccezione successiva.::SQLSTATE: XBM0C
> >
> > Thanks for the help
> >
> >
> >
> > On Sun, 13 Nov 2022 at 15:26, Bryan Pendleton <
> bpendleton.de...@gmail.com>
> > wrote:
> >
> >> I'm not aware of client-server version incompatibilities. Have you
> >> done any experiments with different versions?
> >>
> >> thanks,
> >>
> >> bryan
> >>
> >> On Thu, Nov 10, 2022 at 4:16 AM fed wrote:
> >>> Hi,
> >>>
> >>> using derby with network server setup is there any problem if the
> server
> >> and the client are running on different java versions?
> >>> Still on this, considering the database created/updated with the apache
> >> derby version that the client uses, is there any problem if the server
> will
> >> use a newer version of apache derby?
> >>> Thanks for the help
> >>>
> >>> -fed
>
>
>
Re: Network server with different java (or derby) version between client and server
Hi, Sorry for the late answer but I lost your reply. Two tests: I have a database updated to version 10.12.1.1, the server is running with the 10.12.1.1 too and the client is using 10.12.1.1 too, the connection is OK, I can use this setup. But another test: still the same database updated to version 10.12.1.1, the server is running 10.15.2.0 so a newer version and the client is using 10.12.1.1: I have problems in this case the client can't connect to the database with this error: Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: ERRORCODE: 4, SQLSTATE: XJ040, SQLERRMC: Impossibile avviare il database '/home/user/some_db_path/' con il caricatore di classi jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc. Per i dettagli, vedere l'eccezione successiva.::SQLSTATE: XBM0C Thanks for the help On Sun, 13 Nov 2022 at 15:26, Bryan Pendleton wrote: > I'm not aware of client-server version incompatibilities. Have you > done any experiments with different versions? > > thanks, > > bryan > > On Thu, Nov 10, 2022 at 4:16 AM fed wrote: > > > > Hi, > > > > using derby with network server setup is there any problem if the server > and the client are running on different java versions? > > > > Still on this, considering the database created/updated with the apache > derby version that the client uses, is there any problem if the server will > use a newer version of apache derby? > > > > Thanks for the help > > > > -fed >
Network server with different java (or derby) version between client and server
Hi, using derby with network server setup is there any problem if the server and the client are running on different java versions? Still on this, considering the database created/updated with the apache derby version that the client uses, is there any problem if the server will use a newer version of apache derby? Thanks for the help -fed
Problem upgrading a derby database, ArrayIndexOutOfBoundsException on getIndexInfo()
Hi, I posted time ago on this mailing list a similar question about an upgrading problem but i never found a solution, now i think i have the same problem with another derby database, i hope i can find a solution this time. I have a derby database 10.8.x and i use it with jdo/datanuclues. I am trying to update it to 10.9 but after updating it the database becomes unusable, it gives me an ArrayIndexOutOfBoundsException on conn.getMetaData().getIndexInfo(... ). I don't know very well what creates this error but i try to explain some steps that i found that reproduce it. 1 - I acess the database with some client, for example Squirrel Sql ( squirrel sql uses the 10.9 driver version to access the db). It is not need to execute any query or whatever just access the database and close it. 2 - I update the database from 10.8 -> 10.9 using the upgrade = true properties while connection to it and i close/shutdown the database. 3- from datanucleus i have a tool that generate/update the schema of the database, i run this tool and the operation fails. >From derby.log logs i can see at the end of logs: Sat Jun 30 22:41:55 CEST 2012 Thread[SwingWorker-pool-2-thread-2,5,main] (XID = 89554052), (SESSIONID = 5), (DATABASE = db/rilevdata), (DRDAID = null), Executing prepared statement: EXECUTE STATEMENT SYS."getTables" :End prepared statement with 7 parameters begin parameter #1: % :end parameter begin parameter #2: % :end parameter begin parameter #3: FASCEMONTEORENEW_LISTA :end parameter begin parameter #4: T :end parameter begin parameter #5: V :end parameter begin parameter #6: A :end parameter begin parameter #7: S :end parameter Sat Jun 30 22:41:55 CEST 2012 Thread[SwingWorker-pool-2-thread-2,5,main] (XID = 89554052), (SESSIONID = 5), (DATABASE = db/rilevdata), (DRDAID = null), Begin compiling prepared statement: EXECUTE STATEMENT SYS."getIndexInfo" :End prepared statement Sat Jun 30 22:41:55 CEST 2012 Thread[SwingWorker-pool-2-thread-2,5,main] (XID = 89554052), (SESSIONID = 5), (DATABASE = db/rilevdata), (DRDAID = null), End compiling prepared statement: EXECUTE STATEMENT SYS."getIndexInfo" :End prepared statement Sat Jun 30 22:41:55 CEST 2012 Thread[SwingWorker-pool-2-thread-2,5,main] (XID = 89554052), (SESSIONID = 5), (DATABASE = db/rilevdata), (DRDAID = null), Cleanup action starting Sat Jun 30 22:41:55 CEST 2012 Thread[SwingWorker-pool-2-thread-2,5,main] (XID = 89554052), (SESSIONID = 5), (DATABASE = db/rilevdata), (DRDAID = null), Failed Statement is: null java.lang.ArrayIndexOutOfBoundsException: 4 at org.apache.derby.impl.sql.GenericParameterValueSet.initialize(Unknown Source) at org.apache.derby.impl.sql.execute.BaseActivation.setupActivation(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.(Unknown Source) at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareMetaDataStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.prepareSPS(Unknown Source) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQueryUsingSystemTables(Unknown Source) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(Unknown Source) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(Unknown Source) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.doGetIndexInfo(Unknown Source) at org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getIndexInfo(Unknown Source) at org.apache.commons.dbcp.DelegatingDatabaseMetaData.getIndexInfo(DelegatingDatabaseMetaData.java:327) at org.datanucleus.store.rdbms.schema.RDBMSSchemaHandler.getRDBMSTableIndexInfoForTable(RDBMSSchemaHandler.java:616) at org.datanucleus.store.rdbms.schema.RDBMSSchemaHandler.getRDBMSTableIndexInfoForTable(RDBMSSchemaHandler.java:585) at org.datanucleus.store.rdbms.schema.RDBMSSchemaHandler.getSchemaData(RDBMSSchemaHandler.java:202) at org.datanucleus.store.rdbms.table.TableImpl.getExistingCandidateKeys(TableImpl.java:1097) at org.datanucleus.store.rdbms.table.TableImpl.validateCandidateKeys(TableImpl.java:696) at org.datanucleus.store.rdbms.table.TableImpl.validateConstraints(TableImpl.java:398) at org.datanucleus.store.rdbms.table.ClassTable.validateConstraints(ClassTable.java:3234) at org.datanucleus.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:2827) at org.datanucleus.store.rdbms.RDBMSM
