db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: [Fwd: Re: [Fwd: Problem with derby-dev Digest 2 Jun 2005 20:52:25 -0000 Issue 322 full]]
Date Mon, 06 Jun 2005 15:14:31 GMT
Jeff opened http://issues.apache.org/jira/browse/INFRA-370

  -jean

Philip Wilder wrote:
> Infra has been notified.
> 
> Philip
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [Fwd: Problem with derby-dev Digest 2 Jun 2005 20:52:25 -0000 Issue 
> 322 full]
> From:
> Jeff Turner <jefft@apache.org>
> Date:
> Sun, 5 Jun 2005 18:29:01 -0500
> To:
> Philip Wilder <050503w@acadiau.ca>
> 
> To:
> Philip Wilder <050503w@acadiau.ca>
> 
> 
> On Sat, Jun 04, 2005 at 02:51:14PM -0300, Philip Wilder wrote:
> 
>>Here is the full issue. I can't say this issue has affected me before.
> 
> 
> Thanks.  I reckon it's the digest software that is broken.  For example,
> the summary says:
> 
> [jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server
> 	5078 by: Philip Wilder (JIRA)
> 
> but the actual mail body says:
> 
> Date: Thu, 2 Jun 2005 22:19:02 +0200 (CEST)                                                                                  
> From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>                                                              
> Subject: [jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server              
> To: derby-dev@db.apache.org                                                                                                  
>   
>      [ http://issues.apache.org/jira/browse/DERBY-318?page=all ]
>   
> Samuel Andrew McIntyre updated DERBY-318:
> -----------------------------------------
>   
>     Fix Version: 10.1.0.0
> ....
> 
> 
> I've raised it as a bug with the infrastructure team:
> 
> http://issues.apache.org/jira/browse/INFRA-370
> 
> 
> Cheers,
> Jeff
> 
> 
>>It may be pertinent that I made somewhere in the realm of a half-dozen
>>changes to jira in rapid succession.  As before let me know if there is
>>any way I can help further.
>>
>>Philip Wilder
>>
> 
> 
>>Date: 2 Jun 2005 20:52:25 -0000
>>From: derby-dev-digest-help@db.apache.org
>>Subject: derby-dev Digest 2 Jun 2005 20:52:25 -0000 Issue 322
>>To: derby-dev@db.apache.org
>>
>>
>>derby-dev Digest 2 Jun 2005 20:52:25 -0000 Issue 322
>>
>>Topics (messages 5063 through 5089):
>>
>>Re: Test suite jdbc20 and j9
>>	5063 by: Myrna van Lunteren
>>	5065 by: Daniel John Debrunner
>>
>>Re: Use of DriverManager in tests
>>	5064 by: Daniel John Debrunner
>>	5069 by: Myrna van Lunteren
>>
>>[jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>	5066 by: Philip Wilder (JIRA)
>>	5072 by: Philip Wilder (JIRA)
>>
>>[jira] Updated: (DERBY-121) Network Server reading blob/clob data size
>>	5067 by: Philip Wilder (JIRA)
>>	5073 by: Kathey Marsden
>>	5076 by: Army
>>	5088 by: Philip Wilder (JIRA)
>>	5089 by: Philip Wilder (JIRA)
>>
>>Re: looking for opinions on reasonable hardware requirements for tests in standard derby suite
>>	5068 by: Army
>>
>>[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>	5070 by: Philip Wilder (JIRA)
>>	5071 by: Philip Wilder (JIRA)
>>
>>[jira] Created: (DERBY-333) Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement()
>>	5074 by: Philip Wilder (JIRA)
>>
>>[jira] Commented: (DERBY-17) Network Server Needs to generate CRRTKN on ACCRDB if client does not send it
>>	5075 by: Philip Wilder (JIRA)
>>
>>Re: Implementing Statement.cancel()
>>	5077 by: David Van Couvering
>>
>>[jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server
>>	5078 by: Philip Wilder (JIRA)
>>
>>[jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"
>>	5079 by: Philip Wilder (JIRA)
>>
>>[jira] Updated: (DERBY-322) Remove resultSetHoldability property from ClientDataSource
>>	5080 by: Philip Wilder (JIRA)
>>
>>[jira] Updated: (DERBY-179) Hibernate bad support
>>	5081 by: Philip Wilder (JIRA)
>>
>>[jira] Updated: (DERBY-132) in place table/index compress which returns space to OS
>>	5082 by: Philip Wilder (JIRA)
>>
>>Re: [jira] Updated: (DERBY-247) Network Server demo program should support Derby network client driver
>>	5083 by: Lance J. Andersen
>>	5085 by: Philip Wilder (JIRA)
>>
>>Re: DerbyNetClient/lang/updatableResultSet fails
>>	5084 by: Mamta Satoor
>>
>>[jira] Updated: (DERBY-205) Rename  org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
>>	5086 by: Philip Wilder (JIRA)
>>
>>[jira] Updated: (DERBY-156) Delete with alias on column fails
>>	5087 by: Philip Wilder (JIRA)
>>
>>Administrivia:
>>
>>To subscribe to the digest, e-mail:
>>	derby-dev-digest-subscribe@db.apache.org
>>
>>To unsubscribe from the digest, e-mail:
>>	derby-dev-digest-unsubscribe@db.apache.org
>>
>>To post to the list, e-mail:
>>	derby-dev@db.apache.org
>>
>>
>>----------------------------------------------------------------------
> 
> 
>>Date: Thu, 2 Jun 2005 11:19:17 -0700
>>From: Myrna van Lunteren <m.v.lunteren@gmail.com>
>>Subject: Re: Test suite jdbc20 and j9
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>On 6/2/05, Daniel John Debrunner <djd@debrunners.com> wrote: 
>>
>>>
>>>The test suite jdbc20 currently is not run on j9 (has runwithj9=false in
>>>the jdbc20.properties file). 
>>>
>>>Anyone know why this is?
>>>
>>>The current j9 environment is a full JDK 1.3 environment with JDBC 2.1.
>>>
>>>I tried it out with WCTME 5.7 and jclMax and the tests all pass.
>>>
>>>Dan.
>>>
>>>
>>>
>>
>>I think this must be a left-over of running with an earlier version of j9 
>>which did *not* support jdbc20 functionality.
>>If the tests pass, it's fine. For checks, I ran with wsdd5.6 (j9 2.1), and 
>>all passes with that version too. We don't currently support earlier 
>>versions of j9.
>> Shall I make a patch to remove the runwithj9=false line from this suite, or 
>>can you - as a committer - do that in passing?
>> Myrna
> 
> 
>>Date: Thu, 02 Jun 2005 11:20:41 -0700
>>From: Daniel John Debrunner <djd@debrunners.com>
>>Subject: Re: Test suite jdbc20 and j9
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>Myrna van Lunteren wrote:
>>
>>
>>>On 6/2/05, *Daniel John Debrunner* <djd@debrunners.com
>>><mailto:djd@debrunners.com>> wrote:
>>>
>>>
>>>    The test suite jdbc20 currently is not run on j9 (has runwithj9=false in
>>>    the jdbc20.properties file).
>>>
>>>    Anyone know why this is?
>>>
>>>    The current j9 environment is a full JDK 1.3 environment with JDBC 2.1.
>>>
>>>    I tried it out with WCTME 5.7 and jclMax and the tests all pass.
>>>
>>>    Dan.
>>>
>>>
>>>
>>>I think this must be a left-over of running with an earlier version of
>>>j9 which did *not* support jdbc20 functionality.
>>>If the tests pass, it's fine. For checks, I ran with wsdd5.6 (j9 2.1),
>>>and all passes with that version too. We don't currently support earlier
>>>versions of j9.
>>> 
>>>Shall I make a patch to remove the runwithj9=false line from this suite,
>>>or can you - as a committer - do that in passing?
>>
>>Thanks for running it on 5.6, I was worried what the outcome there might
>>be. I'll address this.
>>
>>Dan.
>>
> 
> 
>>Date: Thu, 02 Jun 2005 07:22:26 -0700
>>From: Daniel John Debrunner <djd@debrunners.com>
>>Subject: Re: Use of DriverManager in tests
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>Øystein Grøvlen wrote:
>>
>>
>>>When developing a test for Derby-230, I was made aware of that we
>>>should not use the DriverManager directly, but instead use
>>>startJBMS().  However, I see some test (e.g.,
>>>store/backupRestore1.java) that uses the DriverManager when shutting
>>>down the database and when doing restore.  I am currently working on a
>>>test for Derby-298 that needs to do the same.  Is it OK to do it this
>>>way?   What restriction does it impose on which environment the test
>>>can be run in? 
>>
>>J2ME does not suport DriverManager. This is because the JDBC JSR169
>>subset only supports javax.sql.DataSource as the connection mechanism.
>>
>>I currently have the test suite running under J2ME with about a 50% pass
>>rate. Many of those failures are due to use of DriverManager, which I
>>will look at fixing in one way or another.
>>
>>So at the momeent I would request anyone to minimize use of
>>DriverManager, but if it is needed then use it.
>>
>>
>>Dan.
>>
>>
> 
> 
>>Date: Thu, 2 Jun 2005 11:39:58 -0700
>>From: Myrna van Lunteren <m.v.lunteren@gmail.com>
>>Subject: Re: Use of DriverManager in tests
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>On 6/2/05, Daniel John Debrunner <djd@debrunners.com> wrote: 
>>
>>>Øystein Grøvlen wrote:
>>>
>>>
>>>>When developing a test for Derby-230, I was made aware of that we
>>>>should not use the DriverManager directly, but instead use
>>>>startJBMS(). However, I see some test (e.g.,
>>>>store/backupRestore1.java) that uses the DriverManager when shutting
>>>>down the database and when doing restore. I am currently working on a
>>>>test for Derby-298 that needs to do the same. Is it OK to do it this
>>>>way? What restriction does it impose on which environment the test
>>>>can be run in?
>>>
>>>J2ME does not suport DriverManager. This is because the JDBC JSR169
>>>subset only supports javax.sql.DataSource as the connection mechanism.
>>>
>>>I currently have the test suite running under J2ME with about a 50% pass
>>>rate. Many of those failures are due to use of DriverManager, which I
>>>will look at fixing in one way or another.
>>>
>>>So at the momeent I would request anyone to minimize use of
>>>DriverManager, but if it is needed then use it.
>>>
>>>
>>>Dan.
>>>
>>>
>>>Before, I mentioned that in RunTest, when running with -Duseprocess=false, 
>>
>>a call is made to DriverManager:
>> try 
>>{
>>java.sql.DriverManager.getConnection("jdbc:derby:;shutdown=true");
>>} 
>>catch (java.sql.SQLException e) 
>>{
>>// ignore the errors, they are expected.
>>}
>>I imagine other tests are doing something similar. Without DriverManager, 
>>this of course results in a ClassNotFoundDef error.
>>I spent some time, after Kathey's suggestion on another branch, to use 
>>...functionTests.util.TestUtil to shutdown the database, and I think this 
>>should work as a replacement for using
>>DriverManager.getConnection("jdbc:derby:<db>;shutdown=true").
>>In the case of RunTest, I'm wary of making big waves, so I am thinking of 
>>changing the above section to:
>>  try 
>>{
>>java.sql.DriverManager.getConnection("jdbc:derby:;shutdown=true");
>>} 
>>catch (java.sql.SQLException e) 
>>{
>>// ignore the errors, they are expected.
>>}
>>// maybe we're running with a DataSource in J2ME.
>>// then we get an ClassNotFoundDef error on DriverManager.getConnection
>>catch (Throwable th) 
>>{
>>Properties attrs = new Properties();
>>attrs.setProperty("shutdownDatabase", "shutdown");
>>try {
>>DataSource ds = TestUtil.getDataSource(attrs);
>>ds.getConnection();
>>} catch (Throwable ith) {
>>ith.printStackTrace();
>>}
>>}
>>
>>Any reason why this would not work? Should we remove the DriverManager call 
>>altogether & replace with the DataSource call?
>> Thx,
>>Myrna
> 
> 
>>Date: Thu, 2 Jun 2005 20:28:55 +0200 (CEST)
>>From: "Philip Wilder (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
>>
>>Philip Wilder reassigned DERBY-213:
>>-----------------------------------
>>
>>    Assign To: Philip Wilder  (was: Kathey Marsden)
>>
>>
>>>ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>>--------------------------------------------------------------------------------------------------
>>>
>>>         Key: DERBY-213
>>>         URL: http://issues.apache.org/jira/browse/DERBY-213
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>>    Reporter: Kathey Marsden
>>>    Assignee: Philip Wilder
>>> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java
>>>
>>>Network Server closes the result set if ResultSet.next() is 
>>>called after the last row of the result set.  The test code 
>>>below throws the following exception.
>>>SQLState:   null
>>>Severity: -99999
>>>Message:  Invalid operation: result set closed
>>>com.ibm.db2.jcc.am.SqlException: Invalid operation: result set 
>>>closed
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j
>>>ava:3419)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277)
>>>        at AfterLast.test(AfterLast.java:75)
>>>        at AfterLast.main(AfterLast.java:32)
>>>stmt.executeUpdate("CREATE  TABLE TAB ( I INT)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(1)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(2)");
>>>String sql ="SELECT * from tab";		
>>>ps = conn.prepareStatement(sql);
>>>ResultSet rs = ps.executeQuery();
>>>System.out.println(sql);
>>>while (rs.next())
>>>System.out.println(rs.getInt(1));
>>>try {
>>>	System.out.println("one more next");
>>>	rs.next();
>>>		}
>>>    catch (Exception e)
>>>		{
>>>		System.out.println("FAIL: next should return false not throw 
>>>exception");
>>>		e.printStackTrace();
>>>		}
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 20:18:07 +0200 (CEST)
>>From: "Philip Wilder (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
>>
>>Philip Wilder reassigned DERBY-213:
>>-----------------------------------
>>
>>    Assign To: Kathey Marsden
>>
>>If Jira does not support multiple assignees, Philip Wilder can also be considered an assignee.
>>
>>
>>>ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>>--------------------------------------------------------------------------------------------------
>>>
>>>         Key: DERBY-213
>>>         URL: http://issues.apache.org/jira/browse/DERBY-213
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>>    Reporter: Kathey Marsden
>>>    Assignee: Kathey Marsden
>>> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java
>>>
>>>Network Server closes the result set if ResultSet.next() is 
>>>called after the last row of the result set.  The test code 
>>>below throws the following exception.
>>>SQLState:   null
>>>Severity: -99999
>>>Message:  Invalid operation: result set closed
>>>com.ibm.db2.jcc.am.SqlException: Invalid operation: result set 
>>>closed
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j
>>>ava:3419)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277)
>>>        at AfterLast.test(AfterLast.java:75)
>>>        at AfterLast.main(AfterLast.java:32)
>>>stmt.executeUpdate("CREATE  TABLE TAB ( I INT)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(1)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(2)");
>>>String sql ="SELECT * from tab";		
>>>ps = conn.prepareStatement(sql);
>>>ResultSet rs = ps.executeQuery();
>>>System.out.println(sql);
>>>while (rs.next())
>>>System.out.println(rs.getInt(1));
>>>try {
>>>	System.out.println("one more next");
>>>	rs.next();
>>>		}
>>>    catch (Exception e)
>>>		{
>>>		System.out.println("FAIL: next should return false not throw 
>>>exception");
>>>		e.printStackTrace();
>>>		}
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 20:28:53 +0200 (CEST)
>>From: "A B (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-121?page=all ]
>>
>>A B updated DERBY-121:
>>----------------------
>>
>>    Attachment: derby-121_2.stat
>>                derby-121_2.patch
>>
>>Attaching patch to test and resolve this issue.  In order to test, I had to create a new suite (separate from "derbyall") since the test case requires more JVM heap size than usual.  The actual fix for the problem is as given in the description for this defect--I made that fix in both the Network Server code and in the Derby Client.
>>
>>
>>>Network Server reading blob/clob data size
>>>------------------------------------------
>>>
>>>         Key: DERBY-121
>>>         URL: http://issues.apache.org/jira/browse/DERBY-121
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>> Environment: The is a bit shift typo in Network Server reading clob/blob data size
>>>    Reporter: Lynh Nguyen
>>>    Priority: Minor
>>> Attachments: derby-121_2.patch, derby-121_2.stat
>>>
>>>in DDMReader.java 
>>>...
>>>... readLengthAndCodePoint() ... { 
>>>...
>>>switch (numberOfExtendedLenBytes) {
>>>			case 8:
>>>				 ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 64) +
>>>					((buffer[pos++] & 0xff) << 56) +
>>>					((buffer[pos++] & 0xff) << 48) +
>>>					((buffer[pos++] & 0xff) << 40) +
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 12;
>>>				break;
>>>			case 6:
>>>				ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 48) +
>>>					((buffer[pos++] & 0xff) << 40) +
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 10;
>>>				break;
>>>			case 4:
>>>				ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 8;
>>>				break;
>>>...
>>>The shift bits should be in order:
>>>0,8,16,24 
>>>0,8,16,24,32,40
>>>0,8,16,24,32,40,48,56
>>>This will only affect the larger clob/blob (over 64K ...)
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 02 Jun 2005 11:47:55 -0700
>>From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
>>Subject: Re: [jira] Updated: (DERBY-121) Network Server reading blob/clob
>> data size
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>A B (JIRA) wrote:
>>
>>
>>>    [ http://issues.apache.org/jira/browse/DERBY-121?page=all ]
>>>
>>>A B updated DERBY-121:
>>>----------------------
>>>
>>>   Attachment: derby-121_2.stat
>>>               derby-121_2.patch
>>>
>>>Attaching patch to test and resolve this issue.  
>>>
>>>
>>
>>Hi Army,
>>
>>I seem to recall that the client also needed the same change in
>>Reply.java. Could you check that?
>>In the test I think we should rename lob64KTable(bl blob(100M);  to
>>something more suited to its size.
>>When you repost your patch could you add a comment that I can use as  a
>>check-in comment.
>>Could you also change the bug description to have the correct size
>>instead of 64K?
>>
>>
>>Thanks
>>
>>Kathey
>>
>>
>>
> 
> 
>>Date: Thu, 02 Jun 2005 11:59:17 -0700
>>From: Army <qozinx@sbcglobal.net>
>>Subject: Re: [jira] Updated: (DERBY-121) Network Server reading blob/clob
>> data size
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>Kathey Marsden wrote:
>>
>>
>>>I seem to recall that the client also needed the same change in
>>>Reply.java. Could you check that?
>>
>>It did, and I think the change is already in the patch (way down at the bottom 
>>of the patch).
>>
>>
>>>In the test I think we should rename lob64KTable(bl blob(100M);  to
>>>something more suited to its size.
>>
>>Oops, sorry.  Yes, I'll rename this.  I pulled it from the JIRA entry when I 
>>first started writing the test, and forgot to change the name later.
>>
>>
>>>When you repost your patch could you add a comment that I can use as  a
>>>check-in comment.
>>
>>Okay.
>>
>>
>>>Could you also change the bug description to have the correct size
>>>instead of 64K?
>>
>>Yep, will do.
>>
>>Army
>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:51:52 +0200 (CEST)
>>From: "A B (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-121?page=all ]
>>
>>A B updated DERBY-121:
>>----------------------
>>
>>    Attachment: derby-121_3.patch
>>
>>Modified patch so that lobLengthTests.java uses a table name that correctly indicates the size of the test table we're using.
>>
>>Also, per Kathey M's request, I'm including a "check-in comment" here:
>>
>>----
>>1) Change Network Server and Derby Client code to do correct bit-shifting when processing the length of LOBs that are larger than 2^24 bytes (DERBY-121).  2) Add a new suite, "largeData", for running tests that require extra machine resources, and add the test for DERBY-121 to that suite (because the test for DERBY-121 requires extra heap memory for the server's JVM).
>>----
>>
>>
>>>Network Server reading blob/clob data size
>>>------------------------------------------
>>>
>>>         Key: DERBY-121
>>>         URL: http://issues.apache.org/jira/browse/DERBY-121
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>> Environment: The is a bit shift typo in Network Server reading clob/blob data size
>>>    Reporter: Lynh Nguyen
>>>    Assignee: A B
>>>    Priority: Minor
>>> Attachments: derby-121_2.stat, derby-121_3.patch
>>>
>>>in DDMReader.java 
>>>...
>>>... readLengthAndCodePoint() ... { 
>>>...
>>>switch (numberOfExtendedLenBytes) {
>>>			case 8:
>>>				 ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 64) +
>>>					((buffer[pos++] & 0xff) << 56) +
>>>					((buffer[pos++] & 0xff) << 48) +
>>>					((buffer[pos++] & 0xff) << 40) +
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 12;
>>>				break;
>>>			case 6:
>>>				ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 48) +
>>>					((buffer[pos++] & 0xff) << 40) +
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 10;
>>>				break;
>>>			case 4:
>>>				ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 8;
>>>				break;
>>>...
>>>The shift bits should be in order:
>>>0,8,16,24 
>>>0,8,16,24,32,40
>>>0,8,16,24,32,40,48,56
>>>This will only affect the larger clob/blob (over 64K ...)
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:52:09 +0200 (CEST)
>>From: "A B (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-121?page=all ]
>>
>>A B updated DERBY-121:
>>----------------------
>>
>>    Description: 
>>in DDMReader.java 
>>...
>>... readLengthAndCodePoint() ... { 
>>...
>>
>>switch (numberOfExtendedLenBytes) {
>>			case 8:
>>				 ddmScalarLen =
>>					((buffer[pos++] & 0xff) << 64) +
>>					((buffer[pos++] & 0xff) << 56) +
>>					((buffer[pos++] & 0xff) << 48) +
>>					((buffer[pos++] & 0xff) << 40) +
>>					((buffer[pos++] & 0xff) << 32) +
>>					((buffer[pos++] & 0xff) << 16) +
>>					((buffer[pos++] & 0xff) << 8) +
>>					((buffer[pos++] & 0xff) << 0);
>>				adjustSize = 12;
>>				break;
>>			case 6:
>>				ddmScalarLen =
>>					((buffer[pos++] & 0xff) << 48) +
>>					((buffer[pos++] & 0xff) << 40) +
>>					((buffer[pos++] & 0xff) << 32) +
>>					((buffer[pos++] & 0xff) << 16) +
>>					((buffer[pos++] & 0xff) << 8) +
>>					((buffer[pos++] & 0xff) << 0);
>>				adjustSize = 10;
>>				break;
>>			case 4:
>>				ddmScalarLen =
>>					((buffer[pos++] & 0xff) << 32) +
>>					((buffer[pos++] & 0xff) << 16) +
>>					((buffer[pos++] & 0xff) << 8) +
>>					((buffer[pos++] & 0xff) << 0);
>>				adjustSize = 8;
>>				break;
>>...
>>The shift bits should be in order:
>>0,8,16,24 
>>0,8,16,24,32,40
>>0,8,16,24,32,40,48,56
>>
>>This will only affect a lob if its length requires at least 24 bits--i.e. if the lob has a length of at least 2^24 bytes.
>>
>>  was:
>>in DDMReader.java 
>>...
>>... readLengthAndCodePoint() ... { 
>>...
>>
>>switch (numberOfExtendedLenBytes) {
>>			case 8:
>>				 ddmScalarLen =
>>					((buffer[pos++] & 0xff) << 64) +
>>					((buffer[pos++] & 0xff) << 56) +
>>					((buffer[pos++] & 0xff) << 48) +
>>					((buffer[pos++] & 0xff) << 40) +
>>					((buffer[pos++] & 0xff) << 32) +
>>					((buffer[pos++] & 0xff) << 16) +
>>					((buffer[pos++] & 0xff) << 8) +
>>					((buffer[pos++] & 0xff) << 0);
>>				adjustSize = 12;
>>				break;
>>			case 6:
>>				ddmScalarLen =
>>					((buffer[pos++] & 0xff) << 48) +
>>					((buffer[pos++] & 0xff) << 40) +
>>					((buffer[pos++] & 0xff) << 32) +
>>					((buffer[pos++] & 0xff) << 16) +
>>					((buffer[pos++] & 0xff) << 8) +
>>					((buffer[pos++] & 0xff) << 0);
>>				adjustSize = 10;
>>				break;
>>			case 4:
>>				ddmScalarLen =
>>					((buffer[pos++] & 0xff) << 32) +
>>					((buffer[pos++] & 0xff) << 16) +
>>					((buffer[pos++] & 0xff) << 8) +
>>					((buffer[pos++] & 0xff) << 0);
>>				adjustSize = 8;
>>				break;
>>...
>>The shift bits should be in order:
>>0,8,16,24 
>>0,8,16,24,32,40
>>0,8,16,24,32,40,48,56
>>
>>This will only affect the larger clob/blob (over 64K ...)
>>
>>
>>
>>
>>>Network Server reading blob/clob data size
>>>------------------------------------------
>>>
>>>         Key: DERBY-121
>>>         URL: http://issues.apache.org/jira/browse/DERBY-121
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>> Environment: The is a bit shift typo in Network Server reading clob/blob data size
>>>    Reporter: Lynh Nguyen
>>>    Assignee: A B
>>>    Priority: Minor
>>> Attachments: derby-121_2.stat, derby-121_3.patch
>>>
>>>in DDMReader.java 
>>>...
>>>... readLengthAndCodePoint() ... { 
>>>...
>>>switch (numberOfExtendedLenBytes) {
>>>			case 8:
>>>				 ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 64) +
>>>					((buffer[pos++] & 0xff) << 56) +
>>>					((buffer[pos++] & 0xff) << 48) +
>>>					((buffer[pos++] & 0xff) << 40) +
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 12;
>>>				break;
>>>			case 6:
>>>				ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 48) +
>>>					((buffer[pos++] & 0xff) << 40) +
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 10;
>>>				break;
>>>			case 4:
>>>				ddmScalarLen =
>>>					((buffer[pos++] & 0xff) << 32) +
>>>					((buffer[pos++] & 0xff) << 16) +
>>>					((buffer[pos++] & 0xff) << 8) +
>>>					((buffer[pos++] & 0xff) << 0);
>>>				adjustSize = 8;
>>>				break;
>>>...
>>>The shift bits should be in order:
>>>0,8,16,24 
>>>0,8,16,24,32,40
>>>0,8,16,24,32,40,48,56
>>>This will only affect a lob if its length requires at least 24 bits--i.e. if the lob has a length of at least 2^24 bytes.
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 02 Jun 2005 11:33:03 -0700
>>From: Army <qozinx@sbcglobal.net>
>>Subject: Re: looking for opinions on reasonable hardware requirements for
>> tests in standard derby suite
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>Øystein Grøvlen wrote:
>>
>>
>>>>>>>>"MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:
>>>
>>>    MM> I would still like almost all tests to be included in derbyall,
>>>    MM> but it would seem reasonable for there to be a small suite
>>>    MM> which hopefully could be set up to be automatically run on
>>>    MM> some interval - worst case at least before a release.
>>>
>>>I agree with you.  We need a testsuite for long-running tests and
>>>large data volumes.  I have a feeling that due to the way we do
>>>testing, the robustness of Derby for large data volumes are not the
>>>best.  I know David had some recovery problems when doing a large data
>>>volume test.
>>>
>>
>>I agree, as well.  And in fact, the need for such a suite came up when I was 
>>working with DERBY-121.  The test case that I wrote for DERBY-121 requires a 
>>rather large LOB to be passed to Network Server, which means the server JVM 
>>needs more heap than usual.  While this probably isn't a "large data volume" 
>>like what you were envisioning, it nonetheless is a similar sort of 
>>thing--namely, it's a test that requires extra machine resources and thus 
>>shouldn't be run as part of "derbyall".
>>
>>As part of my patch for DERBY-121, I created a new suite "largeData" that is 
>>fairly generic and that can (hopefully) be expanded/extended to help satisfy the 
>>requirements described by Mike in this thread.  See the following email for that 
>>patch and a description of what I did with the new suite:
>>
>>http://thread.gmane.org/gmane.comp.apache.db.derby.devel/4843
>>
>>And please make comments if you think the new suite could be organized better to 
>>fit the needs described in this thread (at least, the "large data volumne" 
>>needs).  Remember: the new suite is only meant to be a starting place; it's not 
>>(yet) intended to satsify all of the large data/long-running test requirements...
>>
>>Army
>>
> 
> 
>>Date: Thu, 2 Jun 2005 20:18:06 +0200 (CEST)
>>From: "Philip Wilder (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
>>
>>Philip Wilder updated DERBY-213:
>>--------------------------------
>>
>>    Attachment: resultset.java
>>
>>Update on the previous resultset.java submission
>>
>>
>>>ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>>--------------------------------------------------------------------------------------------------
>>>
>>>         Key: DERBY-213
>>>         URL: http://issues.apache.org/jira/browse/DERBY-213
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>>    Reporter: Kathey Marsden
>>> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java
>>>
>>>Network Server closes the result set if ResultSet.next() is 
>>>called after the last row of the result set.  The test code 
>>>below throws the following exception.
>>>SQLState:   null
>>>Severity: -99999
>>>Message:  Invalid operation: result set closed
>>>com.ibm.db2.jcc.am.SqlException: Invalid operation: result set 
>>>closed
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j
>>>ava:3419)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277)
>>>        at AfterLast.test(AfterLast.java:75)
>>>        at AfterLast.main(AfterLast.java:32)
>>>stmt.executeUpdate("CREATE  TABLE TAB ( I INT)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(1)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(2)");
>>>String sql ="SELECT * from tab";		
>>>ps = conn.prepareStatement(sql);
>>>ResultSet rs = ps.executeQuery();
>>>System.out.println(sql);
>>>while (rs.next())
>>>System.out.println(rs.getInt(1));
>>>try {
>>>	System.out.println("one more next");
>>>	rs.next();
>>>		}
>>>    catch (Exception e)
>>>		{
>>>		System.out.println("FAIL: next should return false not throw 
>>>exception");
>>>		e.printStackTrace();
>>>		}
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 20:18:05 +0200 (CEST)
>>From: "Philip Wilder (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
>>
>>Philip Wilder updated DERBY-213:
>>--------------------------------
>>
>>    Attachment: Client.java
>>
>>Update to previous client submission.
>>
>>
>>>ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
>>>--------------------------------------------------------------------------------------------------
>>>
>>>         Key: DERBY-213
>>>         URL: http://issues.apache.org/jira/browse/DERBY-213
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>>    Reporter: Kathey Marsden
>>> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java
>>>
>>>Network Server closes the result set if ResultSet.next() is 
>>>called after the last row of the result set.  The test code 
>>>below throws the following exception.
>>>SQLState:   null
>>>Severity: -99999
>>>Message:  Invalid operation: result set closed
>>>com.ibm.db2.jcc.am.SqlException: Invalid operation: result set 
>>>closed
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j
>>>ava:3419)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290)
>>>        at 
>>>com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277)
>>>        at AfterLast.test(AfterLast.java:75)
>>>        at AfterLast.main(AfterLast.java:32)
>>>stmt.executeUpdate("CREATE  TABLE TAB ( I INT)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(1)");
>>>stmt.executeUpdate("INSERT INTO TAB VALUES(2)");
>>>String sql ="SELECT * from tab";		
>>>ps = conn.prepareStatement(sql);
>>>ResultSet rs = ps.executeQuery();
>>>System.out.println(sql);
>>>while (rs.next())
>>>System.out.println(rs.getInt(1));
>>>try {
>>>	System.out.println("one more next");
>>>	rs.next();
>>>		}
>>>    catch (Exception e)
>>>		{
>>>		System.out.println("FAIL: next should return false not throw 
>>>exception");
>>>		e.printStackTrace();
>>>		}
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 20:50:52 +0200 (CEST)
>>From: "Philip Wilder (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Created: (DERBY-333) Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement()
>>To: derby-dev@db.apache.org
>>
>>Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement()
>>--------------------------------------------------------------------------------
>>
>>         Key: DERBY-333
>>         URL: http://issues.apache.org/jira/browse/DERBY-333
>>     Project: Derby
>>        Type: Bug
>>  Components: Network Server  
>>    Versions: 10.1.0.0    
>> Environment: ------------------ Java Information ------------------
>>Java Version:    1.4.2_05
>>Java Vendor:     Sun Microsystems Inc.
>>Java home:       C:\Program Files\Java\j2re1.4.2_05
>>Java classpath:  c:\eclipse\db2jcc.jar;c:\eclipse\db2jcc_license_c.jar;C:\derby\derbyRecent\tools\java\jakarta-oro-2.0.8.jar;c:\derby\derbyRecent\classes;.
>>OS name:         Windows XP
>>OS architecture: x86
>>OS version:      5.1
>>Java user name:  050503w
>>Java user home:  C:\Documents and Settings\050503w
>>Java user dir:   C:\derby\derbyRecent\classes
>>java.specification.name: Java Platform API Specification
>>java.specification.version: 1.4
>>--------- Derby Information --------
>>JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
>>[C:\eclipse\db2jcc.jar] 2.4 - (17)
>>[C:\eclipse\db2jcc_license_c.jar] 2.4 - (17)
>>[C:\derby\derbyRecent\classes] 10.1.0.0 alpha - (???)
>>[C:\derby\derbyRecent\classes] 10.1.0.0 alpha - (???)
>>------------------------------------------------------
>>    Reporter: Philip Wilder
>>
>>
>>Semicolon where it should not be (see the <!-- --> comment):
>>
>>	protected DRDAStatement getDRDAStatement(String pkgnamcsn) 
>>		throws SQLException
>>	{
>>		// Need to get the short version because resultSets have different
>>		// corelation ids.
>>		String key = getStmtKey(pkgnamcsn);
>>		DRDAStatement newStmt = null;
>>
>>		// If our current statement doesn't match,retrieve the statement
>>		// and make it current if not null.
>>            // <!-- Note the semicolon after the if statement -->
>>		if (currentStatement == null || 
>>			!key.equals(getStmtKey(currentStatement.getPkgnamcsn()))); 
>>			{
>>				newStmt  = (DRDAStatement) stmtTable.get(key);				
>>			}
>>			
>>			if (newStmt != null)	 // don't blow away currentStatement if we can't find this one
>>				currentStatement = newStmt;
>>			else
>>				return null;
>>
>>		// Set the correct result set.
>>		currentStatement.setCurrentDrdaResultSet(pkgnamcsn);
>>		return currentStatement;
>>	}
>>
>>Solution is to remove the semicolon, all that is needed is a committer.
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 20:07:08 +0200 (CEST)
>>From: "David Van Couvering (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Commented: (DERBY-17) Network Server Needs to generate CRRTKN on ACCRDB if client does not send it
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-17?page=comments#action_66893 ]
>>     
>>David Van Couvering commented on DERBY-17:
>>------------------------------------------
>>
>>I'd like to understand why JCC cannot guarantee uniqueness.  Reading the spec, the CRRTKN is a combination of the specific host and port *of the client* and a long value of the current timestamp, and that's how it's implemented in the client code (although for some reason I don't fully fathom it only uses half of the bytes of each part of the IP address).  Since each client uses a different TPC-IP port, this value should be unique, even across VMs where the timestamp might match.  The timestamp is just intended to guarantee uniqueness within the same VM.  
>>
>>That said, if the CRRTKN is null, yes, according to the spec the network server should generate it.  But unless I can understand how the CRRTKN generated by the client is not unique across VMs, I don't think it makes sense for the client to stop generating the CRRTKN. 
>>
>>
>>>Network Server Needs to generate CRRTKN on ACCRDB if client does not send it
>>>----------------------------------------------------------------------------
>>>
>>>         Key: DERBY-17
>>>         URL: http://issues.apache.org/jira/browse/DERBY-17
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.0.2.0
>>>    Reporter: Ramandeep Kaur
>>>    Priority: Minor
>>
>>>Opening this bug on behalf of Katherine Marsden
>>>--------------------------------------------------------------
>>>JCC cannot guarantee that the CRRTKN that they send is unique 
>>>because it may come from many jvms.
>>>According to the DDM Spec in ACCRDBRM we should generate and 
>>>send CRRTKN if it was not sent to us.
>>>crrtkn INSTANCE_OF CRRTKN - Correlation Token
>>>1810 OPTIONAL
>>>1811 DFTVAL ’’
>>>1812 NOTE Source server product-specific value is used.
>>>1813 This parameter is returned if and only if the
>>>1814 CRRTKN parameter is not received on
>>>1815 ACCRDB.
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 02 Jun 2005 09:34:14 -0700
>>From: David Van Couvering <David.Vancouvering@Sun.COM>
>>Subject: Re: Implementing Statement.cancel()
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>I have had similar difficulties finding navigation paths from one object 
>>to another within the domain of execution contexts.
>>
>>I have been toying with the idea of putting together one or two UML 
>>class diagrams (using an open-source tool, of course :)) to try and show 
>>the relationships between all these numerous classes and interfaces. 
>>Every time I get in there I have to re-learn how the pieces fit 
>>together, and often my internal buffer overflows and I get lost :)
>>
>>It would also be great to document some of the design 
>>principles/approaches to this layer of the code, as it's not at all 
>>clear through reading the code.  I don't have this knowledge, but if 
>>someone who does can type something up, I can try and put it into a form 
>>that can be posted as a paper to the web site.
>>
>>David
>>
>>Daniel John Debrunner wrote:
>>
>>
>>>Oyvind.Bakksjo@sun.com wrote:
>>>
>>>
>>>
>>>>Daniel John Debrunner wrote:
>>>>
>>>>
>>>>
>>>>>Oyvind.Bakksjo@Sun.COM wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I've been looking at implementing Statement.cancel(), and later,
>>>>>>Statement.setQueryTimeout().
>>>>>
>>>>>
>>>>>
>>>>>So, quick summary, that method is not suitable for finding the correct
>>>>>StatementContext from EmbedStatement.cancel().
>>>>>
>>>>>I'll look into how I think you should track down the StatementContext.
>>>>>Dan.
>>>>
>>>>
>>>>Hi Dan,
>>>>
>>>>have you had any time to look into this?
>>>
>>>Not a lot :-(
>>>
>>>I've been thinking about it and there are a couple of issues:
>>>
>>>1) StatementContexts are created dynamically for the current running
>>>statement
>>>
>>>2) Derby does not keep references to application JDBC objects below the
>>>JDBC layer. This is to ensure when any JDBC object (e.g. Statement)
>>>moves out of scope for the application, it will be garbage collected and
>>>lead to its closure.
>>>
>>>I wonder if from a StatementContext you can determine the activation
>>>because that would provide the link to the Statement.
>>>
>>>
>>>Dan.
>>>
>>>
>>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:19:02 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-318?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-318:
>>-----------------------------------------
>>
>>    Fix Version: 10.1.0.0
>>
>>
>>>SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server
>>>--------------------------------------------------------------------------
>>>
>>>         Key: DERBY-318
>>>         URL: http://issues.apache.org/jira/browse/DERBY-318
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>> Environment: Derby in Network Server mode with either JCC or Derby Net Client.
>>>    Reporter: A B
>>>     Fix For: 10.1.0.0
>>> Attachments: DERBY-318.patch, derbyall_diff.txt
>>>
>>>When connected to the Derby Network Server, if one has a table with a column defined as "GENERATED BY DEFAULT" and then one tries to select the "COLUMNDEFAULT" field from SYS.SYSCOLUMNS, the result is an NPE in the server code that leads to connection deallocation.
>>>I don't know if this is a problem with the "GENERATED BY DEFAULT" feature or if it's a problem with Network Server--more investigation is required.
>>>To reproduce, use ij to connect to a database using Network Server, and then:
>>>ij> create table t1 (i int generated by default as identity);
>>>0 rows inserted/updated/deleted
>>>ij> select columndefault from sys.syscolumns;
>>>COLUMNDEFAULT
>>>----------------------------------------------------------------------------------------------------
>>>----------------------------
>>>null
>>>java.lang.NullPointerException
>>>        at org.apache.derby.impl.drda.DRDAConnThread.writeFdocaVal(DRDAConnThread.java:6550)
>>>        at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.java:5973)
>>>        at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnThread.java:5796)
>>>        at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:595)
>>>        at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226)
>>>agentThread[DRDAConnThread_2,5,main]
>>>ERROR 58009: Execution failed due to a distribution protocol error that caused deallocation of the conversation.  A DRDA Data Stream Syntax Error was detected.  Reason: 0x3
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:18:57 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-308?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-308:
>>-----------------------------------------
>>
>>        Version: 10.1.0.0
>>    Fix Version: 10.1.0.0
>>
>>
>>>Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY"
>>>-----------------------------------------------------------
>>>
>>>         Key: DERBY-308
>>>         URL: http://issues.apache.org/jira/browse/DERBY-308
>>>     Project: Derby
>>>        Type: Sub-task
>>>    Versions: 10.1.0.0
>>>    Reporter: Tomohito Nakayama
>>>    Assignee: Tomohito Nakayama
>>>     Fix For: 10.1.0.0
>>> Attachments: DERBY-308.patch
>>>
>>>The Derby "dblook" utility needs to support "GENERATED BY DEFAULT AS IDENTITY".
>>>This issue was notified in next mail.
>>>http://article.gmane.org/gmane.comp.apache.db.derby.devel/4096
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:19:25 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-322) Remove resultSetHoldability property from ClientDataSource
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-322?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-322:
>>-----------------------------------------
>>
>>    Fix Version: 10.1.0.0
>>
>>
>>>Remove resultSetHoldability property from ClientDataSource
>>>----------------------------------------------------------
>>>
>>>         Key: DERBY-322
>>>         URL: http://issues.apache.org/jira/browse/DERBY-322
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: JDBC, Network Client
>>>    Versions: 10.1.0.0
>>>    Reporter: Daniel John Debrunner
>>>     Fix For: 10.1.0.0
>>
>>>ClientDataSource (through ClientBaseDataSource) implements a Java Bean property resultSetHoldability which is not documented in the functional spec at.
>>>http://incubator.apache.org/derby/papers/DerbyClientSpec.html
>>>JDBC provides standard ways to set the holdability of ResultSets, so a non-standard separate mechanism is not required. The property and associated code needs to be removed.
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:19:30 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-179) Hibernate bad support
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-179?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-179:
>>-----------------------------------------
>>
>>    Priority: Major  (was: Blocker)
>>
>>
>>>Hibernate bad support
>>>---------------------
>>>
>>>         Key: DERBY-179
>>>         URL: http://issues.apache.org/jira/browse/DERBY-179
>>>     Project: Derby
>>>        Type: Bug
>>>  Components: SQL
>>>    Versions: 10.0.2.1
>>> Environment: SUN JDK 1.4
>>>Hibernate 2.1.8
>>>    Reporter: dju dju
>>
>>>When trying to use Derby with the Hibernate basic example (auction system - ant eg) I get the following error . I have being using the Derby Dialect posted at http://opensource.atlassian.com/projects/hibernate/browse/HB-1224
>>>Here is the error message:
>>>===============================================================================
>>>     [java] Hibernate: select * from ( select rownumber() over(order by  auctionite0_.ends desc) as rownumber_, auctionite0_.id as id0_, bids1_.id as id1_, user2_.id as id2_, auctionite0_.description as descript2_0_, auctionite0_.ends as ends0_, auctionite0_.condition as condition0_, auctionite0_.seller as seller0_, auctionite0_.successfulBid as successf6_0_, bids1_.isBuyNow as isBuyNow1_, bids1_.amount as amount1_, bids1_.datetime as datetime1_, bids1_.bidder as bidder1_, bids1_.item as item1_, user2_.userName as userName2_, user2_."password" as y3_2_, user2_.email as email2_, user2_.firstName as firstName2_, user2_."initial" as y6_2_, user2_.lastName as lastName2_, bids1_.item as item__, bids1_.id as id__ from AuctionItem auctionite0_ left outer join Bid bids1_ on auctionite0_.id=bids1_.item left outer join AuctionUser user2_
>>>on bids1_.bidder=user2_.id order by  auctionite0_.ends desc ) as temp_ where rownumber_ <= ?
>>>     [java] 15:16:29,959  WARN JDBCExceptionReporter:57 - SQL Error: -1, SQLState: 42X01
>>>     [java] 15:16:29,959 ERROR JDBCExceptionReporter:58 - DB2 SQL error: SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount
>>>ered "(" at line 1, column 40¶42X01
>>>     [java] 15:16:29,990  WARN JDBCExceptionReporter:57 - SQL Error: -1, SQLState: 42X01
>>>     [java] 15:16:29,990 ERROR JDBCExceptionReporter:58 - DB2 SQL error: SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount
>>>ered "(" at line 1, column 40¶42X01
>>>     [java] net.sf.hibernate.exception.SQLGrammarException: Could not execute query
>>>     [java]     at net.sf.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:58)
>>>     [java]     at net.sf.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
>>>     [java]     at net.sf.hibernate.impl.SessionImpl.convert(SessionImpl.java:4131)
>>>     [java]     at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1557)
>>>     [java]     at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:49)
>>>     [java]     at org.hibernate.auction.Main.viewAllAuctionsSlow(Main.java:86)
>>>     [java]     at org.hibernate.auction.Main.main(Main.java:366)
>>>Can you help with this? 
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:19:22 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-132) in place table/index compress which returns space to OS
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-132?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-132:
>>-----------------------------------------
>>
>>    Fix Version: 10.1.0.0
>>
>>
>>>in place table/index compress which returns space to OS
>>>-------------------------------------------------------
>>>
>>>         Key: DERBY-132
>>>         URL: http://issues.apache.org/jira/browse/DERBY-132
>>>     Project: Derby
>>>        Type: Improvement
>>>  Components: Store
>>>    Versions: 10.1.0.0
>>>    Reporter: Mike Matrigali
>>>    Assignee: Mike Matrigali
>>>     Fix For: 10.1.0.0
>>
>>>Each derby table or index is stored in a separate file.  Space from
>>>deleted rows is eventually reclaimed within the file as is used for
>>>subsequent inserts into the same file.  That space is not returned to
>>>the OS unless the user calls the SYSCS_UTIL.SYSCS_COMPRESS_TABLE
>>>system procedure.  That procedure will return the unused space in
>>>the tables and indexes to the OS.  It gets an exclusive lock on the
>>>table, copies all rows in the indexes and the base table into new
>>>compressed files and delete the old files.  Prior to jdk 1.4 this was
>>>the only way to return space from a file to the OS.
>>>In jdk 1.4 RandomAccessFile was enhanced to allow the truncation of a
>>>file, which would return the space at the "end" of the file back to
>>>the OS.  In order to take advantage of this new feature a new
>>>compress feature is needed in derby.
>>>The assumption is that this work will be used in future work which will
>>>automatically schedule this job and others in background, with no
>>>interaction needed from the dba.  The 1st phase of this work will
>>>simply build a procedure that will do the work.  The 2nd phase will
>>>be to look into scheduling the procedure automatically as part of
>>>the current background post commit processing.  Longer term it would
>>>be best if this fit into a new background task monitor, which could
>>>schedule larger background tasks balanced against the other priorities
>>>of the system.  These tasks might include: this new online compress,
>>>automatic statistics gathering, more proactive deleted row reclamation, ....
>>>The proposed feature will reorganize base tables and indexes, moving
>>>empty pages to the "end".  It will release space back to the operating
>>>system when it has created a chunk of empty pages at the end of the
>>>file.  It will be designed to run in background, and will lock resources
>>>of the table for as short a time as possible so that it can iteratively
>>>process the table.
>>>To reclaim space in the heap, it will scan the heap in page reverse order.
>>>It will get a short term table lock, process all the rows on a page, and
>>>then commit that transaction releasing the lock.  The commit will be
>>>optimized like other internal transactions, and will not need to wait
>>>for a synchonized write.  Each row moved, will require all the index
>>>entries for that row to also be updated.  While doing the processing it
>>>will also take care of processing committed deleted rows.  When space
>>>is free at the end of the table it will be freed back to the operating
>>>system, using the RandomAccessFile.setLength() interface.
>>>To reclaim space in the btree, data on pages will be moved rather than
>>>rows.  Data from pages at the end of the file will be moved to free
>>>smaller numbered pages.  Again short term table locks will be required,
>>>and the operation will look similar to the current btree merge operations
>>>already implemented.  Again when a chunk of pages is free at the end of
>>>the file, they will be returned to the OS using the same mechanism as
>>>the heap.
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 02 Jun 2005 16:20:38 -0400
>>From: "Lance J. Andersen" <Lance.Andersen@Sun.COM>
>>Subject: Re: [jira] Updated: (DERBY-247) Network Server demo program should
>> support Derby network client driver
>>To: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>
>>Yes I am.  I just had to put everything on hold for a bit while i got 
>>the JDBC 4.0 spec to early draft review.  I just submitted it today.
>>
>>So i will get back to this now.
>>
>>-Lance
>>
>>Samuel Andrew McIntyre (JIRA) wrote:
>>
>>
>>>    [ http://issues.apache.org/jira/browse/DERBY-247?page=all ]
>>>
>>>Samuel Andrew McIntyre updated DERBY-247:
>>>-----------------------------------------
>>>
>>>   Fix Version: 10.1.0.0
>>>
>>>Lance, are you going to work on the demo part of this bug? If not, feel free to assign it to me.
>>>
>>> 
>>>
>>>
>>>>Network Server demo program should support Derby network client driver
>>>>----------------------------------------------------------------------
>>>>
>>>>        Key: DERBY-247
>>>>        URL: http://issues.apache.org/jira/browse/DERBY-247
>>>>    Project: Derby
>>>>       Type: Improvement
>>>> Components: Demos/Scripts
>>>>   Versions: 10.1.0.0
>>>>   Reporter: Samuel Andrew McIntyre
>>>>   Assignee: Lance Andersen
>>>>   Priority: Minor
>>>>    Fix For: 10.1.0.0
>>>>   
>>>>
>>>
>>> 
>>>
>>>
>>>>Currently, the Network Server demo programs require the IBM Universal JDBC Driver (JCC) for client functionality. The demo should be enhanced to also support using the Derby client driver.
>>>>   
>>>>
>>>
>>> 
>>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:18:53 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-247) Network Server demo program should support Derby network client driver
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-247?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-247:
>>-----------------------------------------
>>
>>    Fix Version: 10.1.0.0
>>
>>Lance, are you going to work on the demo part of this bug? If not, feel free to assign it to me.
>>
>>
>>>Network Server demo program should support Derby network client driver
>>>----------------------------------------------------------------------
>>>
>>>         Key: DERBY-247
>>>         URL: http://issues.apache.org/jira/browse/DERBY-247
>>>     Project: Derby
>>>        Type: Improvement
>>>  Components: Demos/Scripts
>>>    Versions: 10.1.0.0
>>>    Reporter: Samuel Andrew McIntyre
>>>    Assignee: Lance Andersen
>>>    Priority: Minor
>>>     Fix For: 10.1.0.0
>>
>>>Currently, the Network Server demo programs require the IBM Universal JDBC Driver (JCC) for client functionality. The demo should be enhanced to also support using the Derby client driver.
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 13:23:38 -0700
>>From: Mamta Satoor <msatoor@gmail.com>
>>Subject: Re: DerbyNetClient/lang/updatableResultSet fails
>>To: Derby Development <derby-dev@db.apache.org>
>>
>>Hi,
>> I am trying to understand the reasons behind updatableResultset test 
>>failure when using DerbyNetClient. Following is what I have found so far.
>> Satheesh made a checkin on May 25th (revision 178519) to the master file 
>>DerbyNetClient/updatableResultSet.out which was as follows
>>+++ 
>>incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/updatableResultSet.out
>>Wed May 25 12:39:51 2005
>>@@ -307,14 +307,14 @@
>>delete using first resultset
>>attempt to send deleteRow on the same row through a different resultset 
>>should throw an exception
>>SQL State : XCL08
>>-Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>+Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>Move to next row in the 2nd resultset and then delete using the second 
>>resultset
>>Positive Test11 - setting the fetch size to > 1 will be ignored by updatable 
>>resultset. Same as updatable cursors
>>Notice the Fetch Size in run time statistics output.
>>1
>>-----
>>Statement Name:
>>- SQL_CURLH000C54
>>+ SQL_CURLH000C55
>>Statement Text:
>>SELECT * FROM t1 FOR UPDATE of c1
>>Parse Time: 0
>>
>>On May 26th, Bernt reported a diff which is reverse of master update done by 
>>Satheesh. Checkin from today (revision 179592) submitted by David seems to 
>>bring the master back to the state prior to Satheesh's checkin. 
>> Also, Bernt, I looked at 
>>http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.htmland
>>the reason you didn't see the failure on Linux
>>2.4.19 and jdk1.4.2_08 I think is because the test never got run on that 
>>machine for some reason. In the list of tests that ran as part of 
>>derbynetclientmats on Linux 2.4.19 and jdk1.4.2_08, I don't see 
>>updatableResultset test in there. Let me know if I have missed anything. But 
>>if I am right, then we don't need updatableResultSet_sed.properties since we 
>>should get same cursor name irrespective of different platforms. 
>>The only question I have is why did Satheesh need to change the master? I am 
>>running with classes and maybe there is something that shows up only with 
>>the jar files. Satheesh, please let me know if there is an environment that 
>>I have not tested which required the master update.
>> thanks,
>>Mamta
>>
>>On 5/26/05, Bernt M. Johnsen <Bernt.Johnsen@sun.com> wrote: 
>>
>> When running derbyall, DerbyNetClient/lang/updatableResultSet fails
>>
>>>the following way:
>>>
>>>*** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 
>>>23:12:55 ***
>>>Initialize for framework: DerbyNetClient
>>>java -ms16777216 -mx33554432 -
>>>Dderby.system.home=/export/home/tmp/Derby/test/DerbyNetClient/updatableResultSet -
>>>Djava.security.manager -Djava.security.policy=/export/home/tmp/Derby/test/nwsvr.policy -
>>>Dcsinfo.codebase=/export/home/tmp/Derby/ trunk/jars/sane -
>>>Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost org 
>>>.apache.derby.drda.NetworkServerControl start
>>>Attempt to shutdown framework: DerbyNetClient
>>>310 del
>>>< Got expected exception Cursor 'SQL_CURLH000C52' is not on a row.
>>>310a310
>>>
>>>>Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
>>>
>>>317 del
>>>< SQL_CURLH000C55
>>>317a317
>>>
>>>>SQL_CURLH000C54
>>>
>>>Test Failed.
>>>*** End: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:13:22 
>>>***
>>>
>>>(Same error with 1.5 and 1.3)
>>>
>>>I'm running with Linux 2.6.11. What I find strange, is that when I
>>>inspect the test failures in
>>>
>>>http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178249.html
>>>I see that the same test fails in the same way on all platforms,
>>>with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08
>>>
>>>Comment anynone?
>>>--
>>>Bernt Marius Johnsen, Database Technology Group,
>>>Sun Microsystems, Trondheim, Norway
>>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:19:03 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-205) Rename  org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-205?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-205:
>>-----------------------------------------
>>
>>    Fix Version: 10.1.0.0
>>
>>
>>>Rename  org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
>>>-----------------------------------------------------------------------------
>>>
>>>         Key: DERBY-205
>>>         URL: http://issues.apache.org/jira/browse/DERBY-205
>>>     Project: Derby
>>>        Type: Task
>>>  Components: Network Server
>>>    Versions: 10.1.0.0
>>>    Reporter: Kathey Marsden
>>>    Assignee: Dag H. Wanvik
>>>    Priority: Trivial
>>>     Fix For: 10.1.0.0
>>> Attachments: 205b-rev1.diff, 205b-rev1.stat
>>>
>>>For historical reasons the class DB2jServerImpl, which implements the public NetworkServerControl interface is  inappropriately named.  It should be renamed to NetworkServerControlImpl
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
>>Date: Thu, 2 Jun 2005 22:40:59 +0200 (CEST)
>>From: "Samuel Andrew McIntyre (JIRA)" <derby-dev@db.apache.org>
>>Subject: [jira] Updated: (DERBY-156) Delete with alias on column fails
>>To: derby-dev@db.apache.org
>>
>>     [ http://issues.apache.org/jira/browse/DERBY-156?page=all ]
>>
>>Samuel Andrew McIntyre updated DERBY-156:
>>-----------------------------------------
>>
>>        Version: 10.0.2.1
>>                 10.0.2.0
>>                 10.0.2.2
>>                 10.1.0.0
>>    Fix Version: 10.1.0.0
>>
>>Marking as Fix in 10.1.0.0 as a patch has been submitted by Shreyas Kaushik and is in review.
>>
>>
>>>Delete with alias on column fails
>>>---------------------------------
>>>
>>>         Key: DERBY-156
>>>         URL: http://issues.apache.org/jira/browse/DERBY-156
>>>     Project: Derby
>>>        Type: New Feature
>>>  Components: SQL
>>>    Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0
>>>    Reporter: Bernd Ruehlicke
>>>    Priority: Critical
>>>     Fix For: 10.1.0.0
>>
>>>DELETE FROM MY_TABLE x WHERE x.MY_COLUMN='value';
>>>fails with 
>>>ERROR 42X01: Syntax error: Encountered "x" at line 1, column 24
>>>This is the core of the problem. I found it form a more complicated statement but it cooks down to that this should work but dose not.
>>>B-)
>>
>>-- 
>>This message is automatically generated by JIRA.
>>-
>>If you think it was sent incorrectly contact one of the administrators:
>>   http://issues.apache.org/jira/secure/Administrators.jspa
>>-
>>For more information on JIRA, see:
>>   http://www.atlassian.com/software/jira
>>
> 
> 
> 
> 


Mime
View raw message