[jira] Created: (DERBY-1331) Derby's set schema behavior is not compliant with SQL 2003 Foundation spec.

Derby's set schema behavior is not compliant with SQL 2003 Foundation spec. - Key: DERBY-1331 URL: http://issues.apache.org/jira/browse/DERBY-1331 Project: Derby Type: Bug Reporter:

[jira] Commented: (DERBY-1331) Derby's set schema behavior is not compliant with SQL 2003 Foundation spec.

[ http://issues.apache.org/jira/browse/DERBY-1331?page=comments#action_12412297 ] Mamta A. Satoor commented on DERBY-1331: Fixing this might cause existing applications to break since they might be written based on Derby's current behavior for 'set

[jira] Commented: (DERBY-900) Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour

[ http://issues.apache.org/jira/browse/DERBY-900?page=comments#action_12412298 ] Andrew McIntyre commented on DERBY-900: --- Committed to 10.1 branch with revision 407473. Remove use of String(byte[]) and String(byte[], int, int) constructors in

[jira] Commented: (DERBY-900) Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour

[ http://issues.apache.org/jira/browse/DERBY-900?page=comments#action_12412299 ] Andrew McIntyre commented on DERBY-900: --- Sunitha, please close this issue as resolved if there is no further work to be done. Remove use of String(byte[]) and

Re: jdk16 and suite derbyall - 128 failures

Another strange thing about the Nist failures is that if I remove the DB2 driver from the class path when running derbyall the Nist test does no longer fail. As the DB2 driver is not used in the Nist test I can not see why the DB2 driver should make the Nist test fail. Regards, Olav Rick

[jira] Updated: (DERBY-1282) Finish client info api for JDBC4. Compliance task.

[ http://issues.apache.org/jira/browse/DERBY-1282?page=all ] Dyre Tjeldvoll updated DERBY-1282: -- Attachment: derby-1282.v1.diff derby-1282.v1.stat derbyall_report.v1.txt Attaching a patch (v1) for this issue. Some

[jira] Updated: (DERBY-1282) Finish client info api for JDBC4. Compliance task.

[ http://issues.apache.org/jira/browse/DERBY-1282?page=all ] Dyre Tjeldvoll updated DERBY-1282: -- Derby Info: [Patch Available] Finish client info api for JDBC4. Compliance task. -- Key:

Regression Test Failure! - Derby 407340 - Sun DBTG

[Auto-generated mail] *Derby* 407340/2006-05-17 19:46:06 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 130698568 0 104.03% SunOS-5.10_i86pc-i386 Details in

[jira] Created: (DERBY-1332) CallableStatement methods setClob and setBlob should not throw notImplemented exception since they have been implemented in the PreparedStatement implementation.

CallableStatement methods setClob and setBlob should not throw notImplemented exception since they have been implemented in the PreparedStatement implementation.

[jira] Assigned: (DERBY-1332) CallableStatement methods setClob and setBlob should not throw notImplemented exception since they have been implemented in the PreparedStatement implementation.

[ http://issues.apache.org/jira/browse/DERBY-1332?page=all ] V.Narayanan reassigned DERBY-1332: -- Assign To: V.Narayanan CallableStatement methods setClob and setBlob should not throw notImplemented exception since they have been implemented in the

[jira] Resolved: (DERBY-940) Add JDBC 4 Wrapper support

[ http://issues.apache.org/jira/browse/DERBY-940?page=all ] V.Narayanan resolved DERBY-940: --- Fix Version: (was: 10.2.0.0) Resolution: Fixed Derby Info: [Patch Available] Patch for this issue has been submitted and committed. thanx

[jira] Resolved: (DERBY-1254) XAConnection uses NetConnection as underlying physical connection for JDBC4/Java 1.6

[ http://issues.apache.org/jira/browse/DERBY-1254?page=all ] V.Narayanan resolved DERBY-1254: Resolution: Fixed Derby Info: [Patch Available] patch has been submitted and committed. thanx Narayanan XAConnection uses NetConnection as

[jira] Updated: (DERBY-1214) JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes.

[ http://issues.apache.org/jira/browse/DERBY-1214?page=all ] Anurag Shekhar updated DERBY-1214: -- Attachment: derby-1214.diff Description of Patch Modifed classes java/engine/org/apache/derby/iapi/jdbc/BrokeredPreparedStatement40.java

[jira] Resolved: (DERBY-1328) Implementing the free methods in the Clob and Blob interface

[ http://issues.apache.org/jira/browse/DERBY-1328?page=all ] V.Narayanan resolved DERBY-1328: Resolution: Fixed Derby Info: [Patch Available] patch has been submitted and committed. thanx Narayanan Implementing the free methods in the Clob

[jira] Created: (DERBY-1333) create a test suite which uses junit.xa.single property introduced in derby-1214 to run jdbc4 tests in single branched xa transaction to test brokered classes

create a test suite which uses junit.xa.single property introduced in derby-1214 to run jdbc4 tests in single branched xa transaction to test brokered classes

[jira] Resolved: (DERBY-587) Providing JDBC 4.0 support for derby

[ http://issues.apache.org/jira/browse/DERBY-587?page=all ] V.Narayanan resolved DERBY-587: --- Resolution: Fixed Providing JDBC 4.0 support for derby Key: DERBY-587 URL:

[jira] Resolved: (DERBY-796) jdbc 4.0 specific Blob and Clob method support

[ http://issues.apache.org/jira/browse/DERBY-796?page=all ] V.Narayanan resolved DERBY-796: --- Resolution: Fixed jdbc 4.0 specific Blob and Clob method support -- Key: DERBY-796 URL:

Re: Snapshot build problem on trunk

Andrew McIntyre wrote, On 05/17/06 01:37: On 5/16/06, Lars Heill [EMAIL PROTECTED] wrote: Hi, I run a daily clean snapshot build on derby trunk. The last couple of days ant snapshot has failed, saying: BUILD FAILED /home/pakker/derby/code/build.xml:1559:

[jira] Reopened: (DERBY-1136) JDBC driver on rs.getFloat() gives LossOfPrecisionConversionException for float fields containing Float.MAX_VALUE

[ http://issues.apache.org/jira/browse/DERBY-1136?page=all ] Bernt M. Johnsen reopened DERBY-1136: - Merge to 10.1 branch JDBC driver on rs.getFloat() gives LossOfPrecisionConversionException for float fields containing Float.MAX_VALUE

[jira] Resolved: (DERBY-1136) JDBC driver on rs.getFloat() gives LossOfPrecisionConversionException for float fields containing Float.MAX_VALUE

[ http://issues.apache.org/jira/browse/DERBY-1136?page=all ] Bernt M. Johnsen resolved DERBY-1136: - Fix Version: 10.1.3.0 Resolution: Fixed Committed revision 407519 to 10.1 branch NOTE: Regression test (Rev. 389575) not (yet?) merged.

Re: jdk16 and suite derbyall - 128 failures

The exception causing the Nist tests to fail when running derbyall using jdk1.6 has the following call stack: java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read) at

Re: jdk16 and suite derbyall - 128 failures

The AccessControlException thrown in DirStorageFactory.doInit() is caused by the home (directory) variable having the value null. As pointed out by Ole, the Nist tests started to fail in revision r396638 (see DERBY-930). I have run derbyall for r396637 and r396638 with and without the DB2 driver

[jira] Commented: (DERBY-1302) Indent source files touched in DERBY-326

[ http://issues.apache.org/jira/browse/DERBY-1302?page=comments#action_12412342 ] Tomohito Nakayama commented on DERBY-1302: -- Committed. Sendingjava/drda/org/apache/derby/impl/drda/DDMWriter.java Sending

[jira] Commented: (DERBY-1255) Implement new JDBC4 methods for creating empty LOBs in the embedded client

[ http://issues.apache.org/jira/browse/DERBY-1255?page=comments#action_12412343 ] Rick Hillegas commented on DERBY-1255: -- Looks like a solid first increment of support needed for this feature. The jdbc4 tests pass. Derbyall passes modulo wisconsin

[jira] Commented: (DERBY-1255) Implement new JDBC4 methods for creating empty LOBs in the embedded client

[ http://issues.apache.org/jira/browse/DERBY-1255?page=comments#action_12412346 ] V.Narayanan commented on DERBY-1255: Thanx for the commit Rick ! Implement new JDBC4 methods for creating empty LOBs in the embedded client

RE: [jira] Commented: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

I blogged about GROUP BY expression support across dbs a while back (http://tech.puredanger.com/2005/03/02/fun-with-expressions-in-a-group-b y/ and http://tech.puredanger.com/2005/04/01/update-on-expressions-in-group-by/ ). Pretty much all the major vendors support expressions in a GROUP BY. I

[jira] Resolved: (DERBY-1255) Implement new JDBC4 methods for creating empty LOBs in the embedded client

[ http://issues.apache.org/jira/browse/DERBY-1255?page=all ] V.Narayanan resolved DERBY-1255: Resolution: Fixed Implement new JDBC4 methods for creating empty LOBs in the embedded client

[jira] Commented: (DERBY-1214) JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes.

[ http://issues.apache.org/jira/browse/DERBY-1214?page=comments#action_12412350 ] Olav Sandstaa commented on DERBY-1214: -- I have looked at the changes to BrokeredConnection40.java and have only one question/comment. Why does not the createSQLXML()

Regression Test Failure! - TinderBox_Derby 407548 - Sun DBTG

[Auto-generated mail] *TinderBox_Derby* 407548/2006-05-18 15:42:25 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1666665 2 142.43% SunOS-5.10_i86pc-i386 Details in

[jira] Resolved: (DERBY-900) Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour

[ http://issues.apache.org/jira/browse/DERBY-900?page=all ] Sunitha Kambhampati resolved DERBY-900: --- Resolution: Fixed Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable

Re: High throughput, min durability - tuning

Well, I have a couple of thoughts: - Depending upon your OS, often the /tmp directory is actually mapped to memory, not disk. You might try putting your database in /tmp - There has been a proposal and I think some work on implementing an in-memory implementation of the store interface. I

Re: jdk16 and suite derbyall - 128 failures

Looks like a VM bug -- I wonder if their attempt to get the user.dir property in java.io.UnixFileSystem.resolve is likely not encapsulated in a PrivilegedAction block. Olav - why would a null value for user.dir cause a security exception? David Olav Sandstaa wrote: The exception causing the

Re: [Db-derby Wiki] Update of SystemTables by AndrewMcIntyre

I will update this page with 4 new system tables added to support SQL standard authorization mode with support for GRANT/REVOKE. Thanks Andrew, for starting this page.Satheesh On 5/17/06, Apache Wiki [EMAIL PROTECTED] wrote: Dear Wiki user,You have subscribed to a wiki page or wiki category on

Re: jdk16 and suite derbyall - 128 failures

396638 enabled driver autoloading (DERBY-930). It's the patch which required us to migrate to Mustang build 81--that build fixes a bug which short-circuited autoloading from jar files under a SecurityManager. With DERBY-930 in place, the vm will execute its autoloading logic when running

Re: [jira] Commented: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

Thanks Alex, for your message and the blogs... It was an interesting reading. Wonder if MetaMatrix rewrites queries with GROUP BY expressions for Derby into SELECT subqueries... something like:select year(hiredate), month(hiredate) as month, count(*) from employees group by year(hiredate),

[jira] Commented: (DERBY-1282) Finish client info api for JDBC4. Compliance task.

[ http://issues.apache.org/jira/browse/DERBY-1282?page=comments#action_12412404 ] Rick Hillegas commented on DERBY-1282: -- Looks thorough. JDBC4 tests pass. Derbyall passes cleanly except for wisconsin. Committed at subversion revision 407617. Finish

Regression Test Failure! - TinderBox_Derby 407588 - Sun DBTG

[Auto-generated mail] *TinderBox_Derby* 407588/2006-05-18 18:42:53 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1666665 2 143.72% SunOS-5.10_i86pc-i386 Details in

[jira] Commented: (DERBY-1214) JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes.

[ http://issues.apache.org/jira/browse/DERBY-1214?page=comments#action_12412405 ] Rick Hillegas commented on DERBY-1214: -- I'm afraid I can't apply this patch. I get the following errors from the patch tool: patching file

Re: [jira] Commented: (DERBY-1214) JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes.

Did you try reverting your tree to the revision that the patch was made at (svn up -r revision), applying the patch, and then going back to the top of the trunk (svn up)? Often that solves the broken patch problem. David Rick Hillegas (JIRA) wrote: [

[jira] Commented: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=comments#action_12412408 ] Kathey Marsden commented on DERBY-1327: --- I found some good JIT diagnostic info for this JVM at:

[jira] Commented: (DERBY-1214) JDBC4 calls in the Brokered* classes need to be forwarded to more capable classes.

[ http://issues.apache.org/jira/browse/DERBY-1214?page=comments#action_12412409 ] Anurag Shekhar commented on DERBY-1214: --- Looks like It has got some conflict with one of the recent commits. I will reupload it after fixing the conflict and fixing the

[jira] Resolved: (DERBY-1078) Be able to build Derby when JAVA_HOME is set 1.6

[ http://issues.apache.org/jira/browse/DERBY-1078?page=all ] Andrew McIntyre resolved DERBY-1078: Resolution: Fixed Marking this resolved. JDK 1.3.1 tests show several problems, but none related to this issue:

[jira] Updated: (DERBY-1325) Isolation level of local connection does not get reset after exiting a global transaction if the isolation level was changed using SQL

[ http://issues.apache.org/jira/browse/DERBY-1325?page=all ] Deepa Remesh updated DERBY-1325: Attachment: derby-1325-v2.diff derby-1325-v2.status Thanks Kathey and Mamta for looking at the patch. I am attaching an updated patch

[jira] Reopened: (DERBY-1103) Change the client driver to allow statements to be garbage-collected once they are not referenced in an application

[ http://issues.apache.org/jira/browse/DERBY-1103?page=all ] Deepa Remesh reopened DERBY-1103: - Port to 10.1 branch Change the client driver to allow statements to be garbage-collected once they are not referenced in an application

[jira] Updated: (DERBY-1103) Change the client driver to allow statements to be garbage-collected once they are not referenced in an application

[ http://issues.apache.org/jira/browse/DERBY-1103?page=all ] Deepa Remesh updated DERBY-1103: Fix Version: 10.1.3.0 Change the client driver to allow statements to be garbage-collected once they are not referenced in an application

Re: jdk16 and suite derbyall - 128 failures

I am not convinced that this is a VM bug yet. Since the Nist tests run without this problem by either excluding the DB2 driver from the path or by backing out DERBY-930 I still think it is something in the test framework that is causing the problem. I think the security exception occurs due

Re: jdk16 and suite derbyall - 128 failures

Rick Hillegas wrote: 396638 enabled driver autoloading (DERBY-930). It's the patch which required us to migrate to Mustang build 81--that build fixes a bug which short-circuited autoloading from jar files under a SecurityManager. With DERBY-930 in place, the vm will execute its autoloading

[jira] Updated: (DERBY-1272) Change sysinfo to print to error log (derby.log) on boot of derby if derby.stream.error.logSeverityLevel=0

[ http://issues.apache.org/jira/browse/DERBY-1272?page=all ] Andrew McIntyre updated DERBY-1272: --- Attachment: derby-1272-pre.diff Q-n-D patch for this. Would love to get some feedback on whether this is acceptable and the right place for this or if I

[jira] Commented: (DERBY-1141) test harness usage of useprocess needs improvement

[ http://issues.apache.org/jira/browse/DERBY-1141?page=comments#action_12412432 ] Andrew McIntyre commented on DERBY-1141: Committed patch 20060512 with revision 407637. Leaving this open in case anyone else wants to work on it further. test

[jira] Commented: (DERBY-892) add mechanism for specifying policy file for individual function tests

[ http://issues.apache.org/jira/browse/DERBY-892?page=comments#action_12412433 ] Andrew McIntyre commented on DERBY-892: --- Wow, thanks for cooking up a great patch from my half-baked idea. This looks good, I've gone ahead and committed what you have

Regression Test Failure! - TinderBox_Derby 407622 - Sun DBTG

[Auto-generated mail] *TinderBox_Derby* 407622/2006-05-18 21:43:22 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1666665 2 143.59% SunOS-5.10_i86pc-i386 Details in

Re: jdk16 and suite derbyall - 128 failures

Olav Sandstaa wrote: Rick Hillegas wrote: 396638 enabled driver autoloading (DERBY-930). It's the patch which required us to migrate to Mustang build 81--that build fixes a bug which short-circuited autoloading from jar files under a SecurityManager. With DERBY-930 in place, the vm will

[jira] Updated: (DERBY-1323) Detectability methods rowUpdated, rowInserted, rowDeleted can be called from illegal states in both clients

[ http://issues.apache.org/jira/browse/DERBY-1323?page=all ] Dag H. Wanvik updated DERBY-1323: - Attachment: DERBY-1323-2.stat DERBY-1323-2.diff This is version 2 of this patch. It addresses both comments of Fernanda's review. Changes

[jira] Commented: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=comments#action_12412448 ] Kathey Marsden commented on DERBY-1327: --- The problem seems to be in the compilation of this constructor call. The parameter for autoincStart gets compiled incorrectly.

[jira] Commented: (DERBY-1322) Missing resets of isOnInsertRow state in net client when navigating away via other than ResultSet#next

[ http://issues.apache.org/jira/browse/DERBY-1322?page=comments#action_12412454 ] Dag H. Wanvik commented on DERBY-1322: -- The patch looks good. I verified that the changed SURTest.java exposes the problem when run without the rest of the patch, and is

Re: jdk16 and suite derbyall - 128 failures

On 5/18/06, Ole Solberg [EMAIL PROTECTED] wrote: Olav Sandstaa wrote: Rick Hillegas wrote: 396638 enabled driver autoloading (DERBY-930). It's the patch which required us to migrate to Mustang build 81--that build fixes a bug which short-circuited autoloading from jar files under a

Re: LargeCodegen test fails with derbyclient while running largeData test suite

Well, so far we are having problem with lower java heap size for largeCodeGen test only. For largeCodeGen, heap size needs to be increased as follows: - For framework embedded, simply need tochange largeCodeGen_app.properties. So there is no problem with this scenario. - For framework

[jira] Assigned: (DERBY-1323) Detectability methods rowUpdated, rowInserted, rowDeleted can be called from illegal states in both clients

[ http://issues.apache.org/jira/browse/DERBY-1323?page=all ] Dag H. Wanvik reassigned DERBY-1323: Assign To: Dag H. Wanvik Detectability methods rowUpdated, rowInserted, rowDeleted can be called from illegal states in both clients

[jira] Closed: (DERBY-722) updateRow invalidates current row in result set

[ http://issues.apache.org/jira/browse/DERBY-722?page=all ] Dag H. Wanvik closed DERBY-722: --- Resolution: Invalid This is a feature of DERBY wrt FORWARD_ONLY updatables result sets. Closing this in favour of DERBY-1250. updateRow invalidates current

[jira] Closed: (DERBY-1266) Client: Attempted deleteRow or updateRow while on insert row gives wrong error message

[ http://issues.apache.org/jira/browse/DERBY-1266?page=all ] Dag H. Wanvik closed DERBY-1266: Fixed. Client: Attempted deleteRow or updateRow while on insert row gives wrong error message

RE: [jira] Commented: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

No, we don't go quite that far. Because most dbs support group by expressions, we haven't needed to implement this. From: Satheesh Bandaram [mailto:[EMAIL PROTECTED] Sent: Thursday, May 18, 2006 2:16 PMTo: derby-dev@db.apache.orgSubject: Re: [jira] Commented: (DERBY-883) Enhance GROUP