Re: NULL returned from the SYSCS_UTIL.SYSCS_GET_USER_ACCESS system procedure

Laura Stewart wrote: Does anyone know when NULL is returned from the SYSCS_UTIL.SYSCS_GET_USER_ACCESS system procedure ? This question was answered in Jira issue DERBY-2914 and was sent to derby-dev. The answer was: NULL is never returned from SYSCS_UTIL.SYSCS_GET_USER_ACCESS function.

Getting Constraints 'SQL071017145943950' and 'SQL071017145906390' have the same set of columns, which is not allowed. while adding a Unique/primary key constraint to the table

Hi, I have executed the following queries on a table in the given order and I am getting the error mentioned below. I have created a table and then created an unique index on two columns for the table. I have used the same two columns to add a primary key for the table and then used a

Re: Getting Constraints 'SQL071017145943950' and 'SQL071017145906390' have the same set of columns, which is not allowed. while adding a Unique/primary key constraint to the table

Hi Suman, What you're doing here is to first make the attribute pair (LOCALEIDENTIFIER, TEMPLATEID) a primary key, and then give the same attribute pair a unique constraint. The primary key constraint guarantees uniqueness, and step IV is therefore not allowed and results in an exception

RE: Getting Constraints 'SQL071017145943950' and 'SQL071017145906390' have the same set of columns, which is not allowed. while adding a Unique/primary key constraint to the table

Hi Jørgen, Thank you very much for the speedy reply. But the same queries seem to work when I execute them in DB2 and Oracle. Is this behavior only subjective to Derby database? Thanks Regards, Suman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

Re: Getting Constraints 'SQL071017145943950' and 'SQL071017145906390' have the same set of columns, which is not allowed. while adding a Unique/primary key constraint to the table

Hi, I don't know whether this is allowed in other databases, but defining the primary key unique would in any case be redundant since that is implied by the primary key constraint. Regards, Jørgen Suman N wrote: Hi Jørgen, Thank you very much for the speedy reply. But the same queries

Re: Q: alter table to set default column values..

The following error message is obtained: ALTER TABLE T_RES_FILESYSTEM ALTER COLUMN GROUP_ID DEFAULT -1 org.apache.derby.client.am.SqlException: Syntax error: Encountered DEFAULT at line 1, column 53. ALTER COLUMN DEFAULT was added in Derby 10.2.2.0. Are you using Derby 10.2.2.0 or higher?

Re: Q: alter table to set default column values..

The following error message is obtained: ALTER TABLE T_RES_FILESYSTEM ALTER COLUMN GROUP_ID DEFAULT -1 org.apache.derby.client.am.SqlException: Syntax error: Encountered DEFAULT at line 1, column 53. at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source) at

Re: Getting Constraints 'SQL071017145943950' and 'SQL071017145906390' have the same set of columns, which is not allowed. while adding a Unique/primary key constraint to the table

Hi Suman, You do not get any extra value from II or IV. It's sufficient to have the primary key on the two columns. That gives you uniqueness for the columns and so an extra uniqueness constraint is redundant, and, well, erroneous. Craig On Oct 17, 2007, at 3:46 AM, Suman N wrote: Hi,

Is it any optimization for BATCH queries for Derby?

Is it any optimization for BATCH queries for Derby? how about the speed for inserts? which one will be suitable for batchquery? the statement or preparestatement ? it seems a little bit slow to insert a bunch of data into the DB. it is about 7ms for ORACLE (100 queries in batch) but it tooks