date:20060131

[ 
http://issues.apache.org/jira/browse/DERBY-880?page=comments#action_12364615 ] 

Daniel John Debrunner commented on DERBY-880:
-

I don't think this is a regression. Yes, previously you could call 
getXXXStream() in embedded twice on the column to read the stream twice, but 
the second read returned the wrong results. Look at the comments et c. in 
DERBY-721.

The change was  discussed on the list, the JDBC spec says portable code should 
only read a column once.

So now we have getXXXStream(0 calls which can only be called once, and thus 
always return the correct results.

Any applications depending on the old behaviour are returning the worng results 
ot their users.

 jdbcapi/connectionJdbc20.java  fails for server (10.1.2.2) and client 
 (10.2.0.0) compatibility testing with  SQLSTATE(null): 
 java.sql.SQLException: Stream of column value in result cannot be retrieved 
 twice
 ---

  Key: DERBY-880
  URL: http://issues.apache.org/jira/browse/DERBY-880
  Project: Derby
 Type: Bug
   Components: Regression Test Failure, Network Client
 Versions: 10.2.0.0
  Environment: OS: Windows 2000, Server: 10.1.2.2 (372412), Client: 
 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15
 Reporter: Ramandeep Kaur
 Priority: Critical
  Fix For: 10.2.0.0
  Attachments: connectionJdbc20.diff, connectionJdbc20.tmp, 
 connectionJdbc20.tmpmstr

 Ran derby suite derbynetclientmats with Server: 10.1.2.2 (372412), Client: 
 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15 as following:
 1. Create directories for  10.1.2.2 jar files (all jar files except 
 derbyclient.jar) and 10.2.0.0 jars files (only derbyClient.jar).
  2. Set CLASSPATh to the jars in the above directories.
  3. Run suite derbynetclientmats by giving the following command:-
  java org.apache.derbyTesting.functionTests.harness.RunSuite 
 derbynetclientmats
 Test case jdbcapi/connectionJdbc20.java failed with following exception:-
  FAIL -- unexpected exception
  SQLSTATE(null): java.sql.SQLException: Stream of column value in result 
  cannot be retrieved twice
  java.sql.SQLException: Stream of column value in result cannot be retrieved 
  twice
 Test Failed.
 Attaching diff, tmp, and tmpstr.

-- 
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

[jira] Commented: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause

[ 
http://issues.apache.org/jira/browse/DERBY-887?page=comments#action_12364616 ] 

Daniel John Debrunner commented on DERBY-887:
-

Fixing this will also disable previous queries that compiled successfully and 
possibly returned valid results. I couldn't tell from the original 
description if this query was returning all rows in the table.

select id,date from inbox where id = 03

 Select statement returns wrong number of rows if you compare an integer 
 column with a boolean expression in the where clause
 

  Key: DERBY-887
  URL: http://issues.apache.org/jira/browse/DERBY-887
  Project: Derby
 Type: Bug
   Components: SQL
 Versions: 10.2.0.0
  Environment: Java : java version 1.5.0_02
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
 Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
 Classpath : c:/pantry/derby.jar;c:/pantry/derbytools.jar;
 OS: Windows XP Professional
 Reporter: Manjula Kutty
 Priority: Critical
  Fix For: 10.2.0.0
  Attachments: DERBY-887.sql

 I have a table with 2 columns one is BIGINT which is Generated always 
 starting with 1 and increment by1 and the other one is timestamp
  ij select id,date from inbox where id = 03;
 ID  |DATE
 ---
 25  |2006-01-26 14:35:46.584
 34  |2006-01-26 14:36:16.588
 21  |2006-01-26 14:34:46.455
 22  |2006-01-26 14:34:47.176
 27  |2006-01-26 14:35:47.054
 24  |2006-01-26 14:35:16.58
 28  |2006-01-26 14:35:47.305
 35  |2006-01-26 14:36:18.771
 31  |2006-01-26 14:35:48.496
 32  |2006-01-26 14:35:48.887
 33  |2006-01-26 14:35:49.308
 11 rows selected
 ij select id,date from inbox where id = true;
 ID  |DATE
 ---
 21  |2006-01-26 14:34:46.455
 1 row selected
 Both queries should return same number of rows
 Also If I delete the first row from the table then select id,date from inbox 
 where id = true; returns the second row
 ij delete from inbox where id=21;
 1 row inserted/updated/deleted
 Then again run
 ij select id ,date from inbox where id=true;
 ID  |DATE
 ---
 22 |2006-01-26 14:35:16.58
 Which indicates that the select returns only the first row and then is 
 getting closed

-- 
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

Negative test case (Re: [jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client)

2006-01-31 Thread TomohitoNakayama


Hello Kathey.

Kathey Marsden (JIRA) wrote:


In the email:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200601.mbox/[EMAIL 
PROTECTED]
Bryan asked
What sort of faults are we likely to hit? Are things
like corrupt page in database the most likely?

I don't know what is most likely, but I did think of one test case likely to 
cause an IOException.
If the reader is in TRANSACTION_READ_UNCOMMITTED isolation mode and then 
another connection updated the LOB,  the reader  should get an IOException. on 
the next read.

Reading your comment above, I wrote test code attached to this mail, and 
tried executing it with my latest patch, which is not submitted yet.

Then I found no Exception happens at all.

Are there any misunderstanding you in my test code ?
Or is this unlucky success ?

Best regards.

--
/*

   Tomohito Nakayama
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]

   Naka
   http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/ 

/*

Derby - Class org.apache.derbyTesting.functionTests.tests.lang.DirtyReadOfLob

Copyright 1999, 2005 The Apache Software Foundation or its licensors, as 
applicable.

Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

*/

package org.apache.derbyTesting.functionTests.tests.lang;

import java.io.InputStream;
import java.io.ByteArrayInputStream;
import java.sql.Connection;
import java.sql.Statement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;

import java.io.IOException;
import java.sql.SQLException;

import org.apache.derby.tools.ij;

public class DirtyReadOfLob {


public static void main(String[] args){

try{
ij.getPropertyArg(args);


createTestTable();

Connection conn1 = ij.startJBMS();
Connection conn2 = ij.startJBMS();

testDirtyReadOfLob( conn1,
conn2 );

conn1.close();
conn2.close();

}catch(Throwable t){
t.printStackTrace();

}
}


private static void createTestTable() 
throws SQLException,
   IllegalAccessException,
   ClassNotFoundException,
   InstantiationException
{

Connection conn = ij.startJBMS();

Statement createTableSt = conn.createStatement();
createTableSt.execute(create table TEST_TABLE( TEST_COL blob( 512 )));
createTableSt.close();

PreparedStatement insertLobSt = 
conn.prepareStatement(insert into TEST_TABLE( TEST_COL ) 
values(?));

insertLobSt.setBinaryStream(1,createOriginalDataInputStream(),512);
insertLobSt.executeUpdate();

insertLobSt.close();

conn.commit();
conn.close();

}


private static void testDirtyReadOfLob(Connection conn1,
   Connection conn2) 
throws SQLException,
   IOException
{

conn1.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
conn2.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

conn1.setAutoCommit(false);
conn2.setAutoCommit(false);

PreparedStatement st = conn1.prepareStatement(select TEST_COL from 
TEST_TABLE);
ResultSet rs = st.executeQuery();
rs.next();

InputStream is = rs.getBinaryStream(1);

read256Bytes(is);

updateLobValue(conn2);
conn2.commit();

read256Bytes(is);

is.close();
rs.close();
st.close();

conn1.commit();

}


private static ByteArrayInputStream createOriginalDataInputStream(){

byte[] originalValue = new byte[ 512 ];

for(int i = 0; i  originalValue.length; i ++){
originalValue[i] = (byte) (i % 256);
}

return new ByteArrayInputStream(originalValue);

}


private static ByteArrayInputStream createUpdatedDataInputStream(){

byte[] updatedValue = new byte[ 512 ];

for(int i = 0; i  updatedValue.length; i ++){
updatedValue[i] = (byte) ( (updatedValue.length - i) % 256 );
}

return new ByteArrayInputStream(updatedValue);

}


private static void read256Bytes(InputStream is) throws IOException{

for(int

[jira] Commented: (DERBY-880) jdbcapi/connectionJdbc20.java fails for server (10.1.2.2) and client (10.2.0.0) compatibility testing with SQLSTATE(null): java.sql.SQLException: Stream of column valu

[ 
http://issues.apache.org/jira/browse/DERBY-880?page=comments#action_12364617 ] 

Kathey Marsden commented on DERBY-880:
--

Thanks Dan,

It sounds like the best thing to do   is to fix up the 10.1 test  to do the 
right thing and document in the release notes as a change that might affect 
existing applications.

Does that sound correct?



 jdbcapi/connectionJdbc20.java  fails for server (10.1.2.2) and client 
 (10.2.0.0) compatibility testing with  SQLSTATE(null): 
 java.sql.SQLException: Stream of column value in result cannot be retrieved 
 twice
 ---

  Key: DERBY-880
  URL: http://issues.apache.org/jira/browse/DERBY-880
  Project: Derby
 Type: Bug
   Components: Regression Test Failure, Network Client
 Versions: 10.2.0.0
  Environment: OS: Windows 2000, Server: 10.1.2.2 (372412), Client: 
 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15
 Reporter: Ramandeep Kaur
 Priority: Critical
  Fix For: 10.2.0.0
  Attachments: connectionJdbc20.diff, connectionJdbc20.tmp, 
 connectionJdbc20.tmpmstr

 Ran derby suite derbynetclientmats with Server: 10.1.2.2 (372412), Client: 
 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15 as following:
 1. Create directories for  10.1.2.2 jar files (all jar files except 
 derbyclient.jar) and 10.2.0.0 jars files (only derbyClient.jar).
  2. Set CLASSPATh to the jars in the above directories.
  3. Run suite derbynetclientmats by giving the following command:-
  java org.apache.derbyTesting.functionTests.harness.RunSuite 
 derbynetclientmats
 Test case jdbcapi/connectionJdbc20.java failed with following exception:-
  FAIL -- unexpected exception
  SQLSTATE(null): java.sql.SQLException: Stream of column value in result 
  cannot be retrieved twice
  java.sql.SQLException: Stream of column value in result cannot be retrieved 
  twice
 Test Failed.
 Attaching diff, tmp, and tmpstr.

-- 
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

[jira] Assigned: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause

2006-01-31 Thread Rick Hillegas (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-887?page=all ]

Rick Hillegas reassigned DERBY-887:
---

Assign To: Rick Hillegas

 Select statement returns wrong number of rows if you compare an integer 
 column with a boolean expression in the where clause
 

  Key: DERBY-887
  URL: http://issues.apache.org/jira/browse/DERBY-887
  Project: Derby
 Type: Bug
   Components: SQL
 Versions: 10.2.0.0
  Environment: Java : java version 1.5.0_02
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
 Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
 Classpath : c:/pantry/derby.jar;c:/pantry/derbytools.jar;
 OS: Windows XP Professional
 Reporter: Manjula Kutty
 Assignee: Rick Hillegas
 Priority: Critical
  Fix For: 10.2.0.0
  Attachments: DERBY-887.sql

 I have a table with 2 columns one is BIGINT which is Generated always 
 starting with 1 and increment by1 and the other one is timestamp
  ij select id,date from inbox where id = 03;
 ID  |DATE
 ---
 25  |2006-01-26 14:35:46.584
 34  |2006-01-26 14:36:16.588
 21  |2006-01-26 14:34:46.455
 22  |2006-01-26 14:34:47.176
 27  |2006-01-26 14:35:47.054
 24  |2006-01-26 14:35:16.58
 28  |2006-01-26 14:35:47.305
 35  |2006-01-26 14:36:18.771
 31  |2006-01-26 14:35:48.496
 32  |2006-01-26 14:35:48.887
 33  |2006-01-26 14:35:49.308
 11 rows selected
 ij select id,date from inbox where id = true;
 ID  |DATE
 ---
 21  |2006-01-26 14:34:46.455
 1 row selected
 Both queries should return same number of rows
 Also If I delete the first row from the table then select id,date from inbox 
 where id = true; returns the second row
 ij delete from inbox where id=21;
 1 row inserted/updated/deleted
 Then again run
 ij select id ,date from inbox where id=true;
 ID  |DATE
 ---
 22 |2006-01-26 14:35:16.58
 Which indicates that the select returns only the first row and then is 
 getting closed

-- 
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

[jira] Commented: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause

2006-01-31 Thread Rick Hillegas (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-887?page=comments#action_12364633 ] 

Rick Hillegas commented on DERBY-887:
-

If you add an explicit cast to the problem query, it returns correct results:

select * from t where cast(id as boolean) = true;

However, as Bernt points out, the cast (explicit or implicit) is illegal 
according to the ANSI spec.

So, I propose to fix this bug by forbidding these casts, unless someone 
objects. Thanks to Manjula for logging this issue and for everyone's feedback 
so far.

 Select statement returns wrong number of rows if you compare an integer 
 column with a boolean expression in the where clause
 

  Key: DERBY-887
  URL: http://issues.apache.org/jira/browse/DERBY-887
  Project: Derby
 Type: Bug
   Components: SQL
 Versions: 10.2.0.0
  Environment: Java : java version 1.5.0_02
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
 Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
 Classpath : c:/pantry/derby.jar;c:/pantry/derbytools.jar;
 OS: Windows XP Professional
 Reporter: Manjula Kutty
 Assignee: Rick Hillegas
 Priority: Critical
  Fix For: 10.2.0.0
  Attachments: DERBY-887.sql

 I have a table with 2 columns one is BIGINT which is Generated always 
 starting with 1 and increment by1 and the other one is timestamp
  ij select id,date from inbox where id = 03;
 ID  |DATE
 ---
 25  |2006-01-26 14:35:46.584
 34  |2006-01-26 14:36:16.588
 21  |2006-01-26 14:34:46.455
 22  |2006-01-26 14:34:47.176
 27  |2006-01-26 14:35:47.054
 24  |2006-01-26 14:35:16.58
 28  |2006-01-26 14:35:47.305
 35  |2006-01-26 14:36:18.771
 31  |2006-01-26 14:35:48.496
 32  |2006-01-26 14:35:48.887
 33  |2006-01-26 14:35:49.308
 11 rows selected
 ij select id,date from inbox where id = true;
 ID  |DATE
 ---
 21  |2006-01-26 14:34:46.455
 1 row selected
 Both queries should return same number of rows
 Also If I delete the first row from the table then select id,date from inbox 
 where id = true; returns the second row
 ij delete from inbox where id=21;
 1 row inserted/updated/deleted
 Then again run
 ij select id ,date from inbox where id=true;
 ID  |DATE
 ---
 22 |2006-01-26 14:35:16.58
 Which indicates that the select returns only the first row and then is 
 getting closed

-- 
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

[jira] Updated: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

2006-01-31 Thread V.Narayanan (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-856?page=all ]

V.Narayanan updated DERBY-856:
--

Attachment: setCharacterStreamInternal_1.diff

Thanks for the earlier guidance and comments for this patch.

I have modified setCharacterStreamInternal to match changes to 
setBinaryStreamInternal(addressed in DERBY-599)

Issues addressed


a) Have modified it to use newSQLException
b) Fixed the LobLimits test to test when a 4GB blob is inserted

Narayanan

 modify setCharacterStreamInternal to take a long for the length, and perform 
 the  max int check in the method
 --

  Key: DERBY-856
  URL: http://issues.apache.org/jira/browse/DERBY-856
  Project: Derby
 Type: Improvement
   Components: JDBC
 Versions: 10.2.0.0
  Environment: All Environments
 Reporter: V.Narayanan
 Assignee: V.Narayanan
 Priority: Minor
  Attachments: setCharacterStreamInternal.diff, 
 setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff

 A similar change to setBinaryStreamInternal is being handled as part of 
 DERBY-599. 

-- 
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

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

2006-01-31 Thread V.Narayanan (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12364635 ] 

V.Narayanan commented on DERBY-856:
---

Please note that the new patch is setCharacterStreamInternal_1.diff

Narayanan

 modify setCharacterStreamInternal to take a long for the length, and perform 
 the  max int check in the method
 --

  Key: DERBY-856
  URL: http://issues.apache.org/jira/browse/DERBY-856
  Project: Derby
 Type: Improvement
   Components: JDBC
 Versions: 10.2.0.0
  Environment: All Environments
 Reporter: V.Narayanan
 Assignee: V.Narayanan
 Priority: Minor
  Attachments: setCharacterStreamInternal.diff, 
 setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff

 A similar change to setBinaryStreamInternal is being handled as part of 
 DERBY-599. 

-- 
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

[jira] Commented: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

2006-01-31 Thread A B (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-815?page=comments#action_12364637 ] 

A B commented on DERBY-815:
---

 AB, the patch substitutes ArrayLists (not synchronized) for Vectors 
 (synchronized), so with 
 your MT-problems in mind I suggest we get a committer to revert the patch. 

Note that, as I mentioned in my previous comment, I am not able to say with 
certainty that the DERBY-815 patch is responsible for the intermittent 
hang--that has yet to be proven one way or the other.  But that said, if you're 
okay with reverting the patch, I think I would prefer that since I have a lot 
of things on my plate right now and further investigation of this intermittent 
hang may not happen for another couple of days.   

 Maybe I can look at it again when you have committed your work.

I'm not actively working on any changes related to this issue, so I don't think 
there's much point in waiting for me to commit something here ;)  I do have a 
lot of things in progress,  but none address this part of the code: I simply 
noticed that the ODBC tests I have are acting up after DERBY-815 was committed, 
and I was just following up in an attempt to find out why...

If you are willing, I think the best thing here is to revert the patch for now, 
and re-submit it with 1) the fix for the regression, 2) the test case for the 
regression included as part of derbyall, and 3) some additional explanatory 
comments (per my last post).  If you have time to investigate the multithreaded 
angle a bit , that would be _great_; if not, I think we could still commit an 
updated patch and I then can follow-up with more on the multithreaded test case 
when I have time.  If it turns out that the DERBY-815 change are the cause 
(which we don't know yet), I can create another Jira issue with more details...

Does that seem reasonable?

 I must say that it seems very unlikey that DRDAStatements (which originally 
 contained 
 both Vectors and ArrayLists) can be shared between threads. If it worked 
 before it must be 
 by accident...

That could very well be the case; I can't say for sure at this point.

If you are in fact okay with reverting the patch and working on a revised 
version, please post here saying so, and then we can ask a commiter to back the 
change out.

Thanks for your continued follow-up with this issue...

 Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
 -

  Key: DERBY-815
  URL: http://issues.apache.org/jira/browse/DERBY-815
  Project: Derby
 Type: Sub-task
   Components: Network Server, Performance
 Versions: 10.0.2.2, 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 
 10.1.3.0, 10.1.2.2
 Reporter: Knut Anders Hatlen
 Assignee: Dyre Tjeldvoll
 Priority: Minor
  Fix For: 10.2.0.0
  Attachments: d815_regress.diff, d815_regress.java, d815_regress.stat, 
 d815_regress_derbyall_report.txt, derby-815.diff, derby-815.stat, 
 derbyall_report.txt

 Reported by Kathey Marsden in DERBY-212:
 In reviewing the Network Server Code and profiling there were several
 areas that showed potential for providing performance
 improvement. Functions that need optimizing to prevent unneeded object
 creation and excessive decoding: parseSQLDTA_work()

-- 
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

[jira] Commented: (DERBY-868) language specific docs need implemented

2006-01-31 Thread scott hutinger (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12364643 ] 

scott hutinger commented on DERBY-868:
--

Halley Pacheco de Oliveira has an ICLA coming in.  I would agree with Halley, 
that if you click the button when putting files in a JIRA issue, that it's OK 
to use the code, that a ICLA shouldn't be needed.  Although I am not a lawyer, 
I would query Apache to expound a bit about this issue.  It's confusing to 
people, including myself and Halley.

 language specific docs need implemented
 ---

  Key: DERBY-868
  URL: http://issues.apache.org/jira/browse/DERBY-868
  Project: Derby
 Type: Improvement
   Components: Documentation
  Environment: any
 Reporter: scott hutinger
  Attachments: pt_BR_build.diff

 Derby Docs needs to implement languages other than US English somewhat 
 quickly.  Currently a document exists that should be in the build 
 environment.  If no action is taken, this seems to indicate that this is not 
 important.  I feel this is very important myself, although I only speak 
 english and a very small bit of swahili (university course instead of art) :-)
 Currently some architecture needs to be in place to allow for multiple 
 additions of languages fairly easily.  I would vote for a brute force attack 
 and add the current document today, and figure out the architecture in the 
 future.

-- 
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

[jira] Commented: (DERBY-877) zOS - with DerbyClient getDate(#) fails with IllegalArgumentException - unsupported date format - resultset.java

[ 
http://issues.apache.org/jira/browse/DERBY-877?page=comments#action_12364646 ] 

Daniel John Debrunner commented on DERBY-877:
-

This code looks wrong to me, at least it 's deceptive. Here's on example:

+String timestamp = new String(buffer, offset, 
+DateTime.timestampRepresentationLength, encoding);

If the encoding can be changed then the length of the byte representation 
should be changable.
The length here is hard-coded as 26 using the constant 
timestampRepresentationLength.

If really the server is always sending the data with a fixed encoding, which 
looks like the case, then I think the
encoding should be fixed here. Otherwise it looks like the code can handle any 
encoding, and someone in the
future may try to take advantage of that, which may or may not work in some 
cases and fail in others.

 zOS - with DerbyClient getDate(#) fails with IllegalArgumentException - 
 unsupported date format - resultset.java
 

  Key: DERBY-877
  URL: http://issues.apache.org/jira/browse/DERBY-877
  Project: Derby
 Type: Bug
   Components: Network Client
 Versions: 10.1.1.0
  Environment: OS/390 with classic (IBM) jvm142
 Reporter: Myrna van Lunteren
 Assignee: Kathey Marsden
  Attachments: TestEnc.java, derby-877.diff

 The test lang/resultset.java fails with DerbyNetClient on zOS 
 because ResultSet.getDate(#) fails with an 
 java.lang.IllegalArgumentException - unsupported date format.
 This is the stack trace with 10.2 debug version (but it fails 
 with 10.1 also):
 --
 
 getBytes(dt) got exception
 Data Conversion SQLException
 FAIL -- unexpected exception: 
 java.lang.IllegalArgumentException: Unsupported date format!
 java.lang.IllegalArgumentException: Unsupported date format!
 at 
 org.apache.derby.client.am.DateTime.dateBytesToDate(DateTime.java:63)
 at 
 org.apache.derby.client.am.Cursor.getDATE(Cursor.java:400)
 at 
 org.apache.derby.client.am.Cursor.getDate(Cursor.java:712)
 at 
 org.apache.derby.client.am.ResultSet.getDate(ResultSet.java:687)
 at 
 org.apache.derbyTesting.functionTests.tests.jdbcapi.resultset.main(Unknown 
 Source)
 --
 Note: does not fail with jcc.
 Also, test lang/updatableResultSet.java failed with e.g.:
   - instead of 'Got expected exception : Illegal Conversion' :
'Got expected exception : Unsupported date format!' . 
   - instead of 'Got expected exception : Illegal Conversion' :
'Got expected exception : nanos  999 or  0' .

-- 
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

[jira] Commented: (DERBY-868) language specific docs need implemented

[ 
http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12364647 ] 

Daniel John Debrunner commented on DERBY-868:
-

Is more needed on the ICLA than exists at:

http://www.apache.org/licenses/

?

See the 'Contributor License Agreements' section about two-thirds of the way 
down the page.

 language specific docs need implemented
 ---

  Key: DERBY-868
  URL: http://issues.apache.org/jira/browse/DERBY-868
  Project: Derby
 Type: Improvement
   Components: Documentation
  Environment: any
 Reporter: scott hutinger
  Attachments: pt_BR_build.diff

 Derby Docs needs to implement languages other than US English somewhat 
 quickly.  Currently a document exists that should be in the build 
 environment.  If no action is taken, this seems to indicate that this is not 
 important.  I feel this is very important myself, although I only speak 
 english and a very small bit of swahili (university course instead of art) :-)
 Currently some architecture needs to be in place to allow for multiple 
 additions of languages fairly easily.  I would vote for a brute force attack 
 and add the current document today, and figure out the architecture in the 
 future.

-- 
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

[jira] Commented: (DERBY-868) language specific docs need implemented

[ 
http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12364648 ] 

Daniel John Debrunner commented on DERBY-868:
-

To expand a little (I'm not al lawyer etc.):

Submitting a contribution thorugh Jira and clicking the ASL box or the mailing 
lists says you are  licencing this contribution
(to the ASF) under the ASLv2, with the *assumption* that you own the copyright 
 IP of the contribution.

But there are no guarantees to the ASF that you really do own the copyright, 
maybe your employee owns the copyright of
everything you do, maybe you copied the contribution from another open source 
project (under a different license).

The ICLA is the extra step that says everything you contribute to the ASF I do 
have the right to contribute, either
because you own the copyright/IP or your employer owns the copyright/IP and 
they have given permission for the
contribution.



 language specific docs need implemented
 ---

  Key: DERBY-868
  URL: http://issues.apache.org/jira/browse/DERBY-868
  Project: Derby
 Type: Improvement
   Components: Documentation
  Environment: any
 Reporter: scott hutinger
  Attachments: pt_BR_build.diff

 Derby Docs needs to implement languages other than US English somewhat 
 quickly.  Currently a document exists that should be in the build 
 environment.  If no action is taken, this seems to indicate that this is not 
 important.  I feel this is very important myself, although I only speak 
 english and a very small bit of swahili (university course instead of art) :-)
 Currently some architecture needs to be in place to allow for multiple 
 additions of languages fairly easily.  I would vote for a brute force attack 
 and add the current document today, and figure out the architecture in the 
 future.

-- 
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

[jira] Commented: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause

2006-01-31 Thread Rick Hillegas (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-887?page=comments#action_12364649 ] 

Rick Hillegas commented on DERBY-887:
-

Although DERBY-499 introduced some additional casting cases, the root causes of 
this bug are in an older version of Derby. Older releases allow illegal 
comparisons with BOOLEANs. In addition, the problem query can be expressed in a 
way which gets past the 10.1.1.0 parser and produces incorrect results. The 
following incorrect results may be observed in 10.1.1.0:

ij create table t (id bigint generated always as identity (start with 
1,increment by 1), col1 char(2), primary key(id))
;
0 rows inserted/updated/deleted
ij insert into t(col1) values('ca');
1 row inserted/updated/deleted
ij insert into t(col1) values('ba');
1 row inserted/updated/deleted
ij insert into t(col1) values('ea');
1 row inserted/updated/deleted
ij insert into t(col1) values('dd');
1 row inserted/updated/deleted
ij select * from t ;
ID  |COL1
-
1   |ca
2   |ba
3   |ea
4   |dd

4 rows selected
ij select * from t where id=03;
ID  |COL1
-
1   |ca
2   |ba
3   |ea
4   |dd

4 rows selected
ij select * from t where (id=0)3;
ID  |COL1
-
1   |ca
2   |ba
3   |ea
4   |dd

4 rows selected
ij select * from t where id=(03);
ID  |COL1
-
2   |ba

1 row selected

I think there are at least two bugs in here:

o A pre-existing 10.1.1.0 bug.
o Some illegal casts introduced by DERBY-499.



 Select statement returns wrong number of rows if you compare an integer 
 column with a boolean expression in the where clause
 

  Key: DERBY-887
  URL: http://issues.apache.org/jira/browse/DERBY-887
  Project: Derby
 Type: Bug
   Components: SQL
 Versions: 10.2.0.0
  Environment: Java : java version 1.5.0_02
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
 Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
 Classpath : c:/pantry/derby.jar;c:/pantry/derbytools.jar;
 OS: Windows XP Professional
 Reporter: Manjula Kutty
 Assignee: Rick Hillegas
 Priority: Critical
  Fix For: 10.2.0.0
  Attachments: DERBY-887.sql

 I have a table with 2 columns one is BIGINT which is Generated always 
 starting with 1 and increment by1 and the other one is timestamp
  ij select id,date from inbox where id = 03;
 ID  |DATE
 ---
 25  |2006-01-26 14:35:46.584
 34  |2006-01-26 14:36:16.588
 21  |2006-01-26 14:34:46.455
 22  |2006-01-26 14:34:47.176
 27  |2006-01-26 14:35:47.054
 24  |2006-01-26 14:35:16.58
 28  |2006-01-26 14:35:47.305
 35  |2006-01-26 14:36:18.771
 31  |2006-01-26 14:35:48.496
 32  |2006-01-26 14:35:48.887
 33  |2006-01-26 14:35:49.308
 11 rows selected
 ij select id,date from inbox where id = true;
 ID  |DATE
 ---
 21  |2006-01-26 14:34:46.455
 1 row selected
 Both queries should return same number of rows
 Also If I delete the first row from the table then select id,date from inbox 
 where id = true; returns the second row
 ij delete from inbox where id=21;
 1 row inserted/updated/deleted
 Then again run
 ij select id ,date from inbox where id=true;
 ID  |DATE
 ---
 22 |2006-01-26 14:35:16.58
 Which indicates that the select returns only the first row and then is 
 getting closed

-- 
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

[jira] Commented: (DERBY-868) language specific docs need implemented

[ 
http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12364650 ] 

Daniel John Debrunner commented on DERBY-868:
-

Should have been '... to the ASF *you* do have the right ...  in the last 
sentence, not I.

 language specific docs need implemented
 ---

  Key: DERBY-868
  URL: http://issues.apache.org/jira/browse/DERBY-868
  Project: Derby
 Type: Improvement
   Components: Documentation
  Environment: any
 Reporter: scott hutinger
  Attachments: pt_BR_build.diff

 Derby Docs needs to implement languages other than US English somewhat 
 quickly.  Currently a document exists that should be in the build 
 environment.  If no action is taken, this seems to indicate that this is not 
 important.  I feel this is very important myself, although I only speak 
 english and a very small bit of swahili (university course instead of art) :-)
 Currently some architecture needs to be in place to allow for multiple 
 additions of languages fairly easily.  I would vote for a brute force attack 
 and add the current document today, and figure out the architecture in the 
 future.

-- 
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

[jira] Updated: (DERBY-855) Document optimizer overrides which were introduced in 10.2

2006-01-31 Thread Eric Radzinski (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-855?page=all ]

Eric Radzinski updated DERBY-855:
-

Attachment: ctunoptimzoverride.html

I think the most recent ctunoptimzoverride.htm addresses your first two issues 
(adding a pointer to the runtimestats topic and removing the space between 
nested and loop).  The third issue is a simple change that I'll make as soon as 
I add these two new topics to the ditamap for the tuning guide.
Please let me know if you think these topics are ready to commit.

 Document optimizer overrides which were introduced in 10.2
 --

  Key: DERBY-855
  URL: http://issues.apache.org/jira/browse/DERBY-855
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.2.0.0
 Reporter: Mamta A. Satoor
 Assignee: Eric Radzinski
  Fix For: 10.2.0.0
  Attachments: ctundepthoptover.html, ctunoptimzoverride.html, 
 ctunoptimzoverride.html

 Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric 
 Radzinski is working on the documentation part of the feature. This issue is 
 to keep track of documentation changes.

-- 
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

[jira] Commented: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause

[ 
http://issues.apache.org/jira/browse/DERBY-887?page=comments#action_12364653 ] 

Kathey Marsden commented on DERBY-887:
--

Thanks Rick for looking at this issue.
As part of the fix,  can you add BOOLEAN to the the cast and comparison tables 
in the lang/casting.java test?

Thanks

Kathey


 Select statement returns wrong number of rows if you compare an integer 
 column with a boolean expression in the where clause
 

  Key: DERBY-887
  URL: http://issues.apache.org/jira/browse/DERBY-887
  Project: Derby
 Type: Bug
   Components: SQL
 Versions: 10.2.0.0
  Environment: Java : java version 1.5.0_02
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
 Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
 Classpath : c:/pantry/derby.jar;c:/pantry/derbytools.jar;
 OS: Windows XP Professional
 Reporter: Manjula Kutty
 Assignee: Rick Hillegas
 Priority: Critical
  Fix For: 10.2.0.0
  Attachments: DERBY-887.sql

 I have a table with 2 columns one is BIGINT which is Generated always 
 starting with 1 and increment by1 and the other one is timestamp
  ij select id,date from inbox where id = 03;
 ID  |DATE
 ---
 25  |2006-01-26 14:35:46.584
 34  |2006-01-26 14:36:16.588
 21  |2006-01-26 14:34:46.455
 22  |2006-01-26 14:34:47.176
 27  |2006-01-26 14:35:47.054
 24  |2006-01-26 14:35:16.58
 28  |2006-01-26 14:35:47.305
 35  |2006-01-26 14:36:18.771
 31  |2006-01-26 14:35:48.496
 32  |2006-01-26 14:35:48.887
 33  |2006-01-26 14:35:49.308
 11 rows selected
 ij select id,date from inbox where id = true;
 ID  |DATE
 ---
 21  |2006-01-26 14:34:46.455
 1 row selected
 Both queries should return same number of rows
 Also If I delete the first row from the table then select id,date from inbox 
 where id = true; returns the second row
 ij delete from inbox where id=21;
 1 row inserted/updated/deleted
 Then again run
 ij select id ,date from inbox where id=true;
 ID  |DATE
 ---
 22 |2006-01-26 14:35:16.58
 Which indicates that the select returns only the first row and then is 
 getting closed

-- 
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

[jira] Commented: (DERBY-868) language specific docs need implemented

2006-01-31 Thread scott hutinger (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12364654 ] 

scott hutinger commented on DERBY-868:
--

Ok, you have the right :-)  But I'm a bit uncertain about 'which right's' are 
given if an ICLA still is needed.  But that's OK, I don't understand lot's of 
things.

But it looks like Jean and Andrew has taken care of everything to get Halley's 
translation up and running once the ICLA comes in.  Thanks everyone, and this 
is really cool :-)

 language specific docs need implemented
 ---

  Key: DERBY-868
  URL: http://issues.apache.org/jira/browse/DERBY-868
  Project: Derby
 Type: Improvement
   Components: Documentation
  Environment: any
 Reporter: scott hutinger
  Attachments: pt_BR_build.diff

 Derby Docs needs to implement languages other than US English somewhat 
 quickly.  Currently a document exists that should be in the build 
 environment.  If no action is taken, this seems to indicate that this is not 
 important.  I feel this is very important myself, although I only speak 
 english and a very small bit of swahili (university course instead of art) :-)
 Currently some architecture needs to be in place to allow for multiple 
 additions of languages fairly easily.  I would vote for a brute force attack 
 and add the current document today, and figure out the architecture in the 
 future.

-- 
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

[jira] Commented: (DERBY-855) Document optimizer overrides which were introduced in 10.2

2006-01-31 Thread Mamta A. Satoor (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-855?page=comments#action_12364658 ] 

Mamta A. Satoor commented on DERBY-855:
---

Eric, Thanks for taking care of my comments. The changes look good. Dan had 
couple comments too, which I don't think are not covered in your most recent 
changes, but maybe you are still working on it. 

 Document optimizer overrides which were introduced in 10.2
 --

  Key: DERBY-855
  URL: http://issues.apache.org/jira/browse/DERBY-855
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.2.0.0
 Reporter: Mamta A. Satoor
 Assignee: Eric Radzinski
  Fix For: 10.2.0.0
  Attachments: ctundepthoptover.html, ctunoptimzoverride.html, 
 ctunoptimzoverride.html

 Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric 
 Radzinski is working on the documentation part of the feature. This issue is 
 to keep track of documentation changes.

-- 
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

Re: testing using remote host

After some (re)experimenting and dabbing in the permissions I am revisiting this...

As I understand it, there is no way (would violate some basic security concepts) for the networkserver to drop databases, or create subdirectories. (correct?)

Thus, when running against a networkserver on another system/IP address, all databases get created where the networkserver is running (possibly redirected, but it is still afixed location). Thus databases are reused. In this, it is *like* running with useprocess false.

And yes, alas,this means a horrible mess catching up because test changes leave stuff behind. Thus, as I said in email to the list in December, I tried to make tests pass with useprocess=false as much as possible.

I think, also, that when I first ran with useprocess=false, various security permissions error went away, and I thought that I was doing the right thing. However, after I sawthe securitymanager/useprocess=false checkin, I became suspicious of that conclusion, and thus I had to revisit. I felt it was my responsibility rather than simply complain.

I apologize for providing inaccurate informationin my first reply on this thread, I hadn't thoughtit allthrough, and had forgotten some of the behaviour I had seen while experimenting in the month or so between my initial check-in and the question starting this thread. So, no, there is no problem on the serverside with permissions or creation of databases. Rather, there were problems because of reusing of databases and security trouble on the clientside.

Theclientside securitymanager troubles are essentially resolved by making the hostName test property automatically getting passed into the ${derbyTesting.serverhost} (renamed from $csinfo.serverhost) property in jvm.java
which resolves the property in derby_tests.policy. (I did this in my inital patch for DERBY-871).

Now, I would stilllike topursue the useprocess=false angle a little.
In my thinking, it would kill 2 birds with one stone - speed up processing and make every developer responsible for cleaning up their tests instead of putting that burden on myself or whomever actually tries to test with remote host.In theory everyone *should* cleanup the tests objects they create anyways, so I didn't think it anunreasonable hardship. As you might have noticed, I didtake it onto get things a fair ways.

I had jdbc20 suite almost running with useprocess=false...except for
- jdbcapi/getCurConnJdbc20.java when running with db2jcc in the classpath.
It hits:
ERROR XJ001: Java exception: 'access denied ( java.lang.RuntimePermission loadLibrary.db2jcct2): java.security.AccessControlException'
(as I reported to the list).
I think this problem will be resolved by granting db2jcc*.jar all. Ihaven't tested this.But would it be ok? Is there a better approach?

- all tests run witheither JCC or with test property securityManager=false after an initial test has securityManager installed fail because the message 'security Manager not installed' pops up in the test output, instead of the *.sum (or to the console).

This is because it gets generated after the redirection to the stream (from calling the method installManager.
I understand from Dan's reply in this thread and re DERBY-871 that this was because otherwise additional permissions would be needed.I never saw errors relating to the stream, but then I was running with the classes - could that make a difference? What would be the behavio(u)r if you'd get the permission error? Maybe I saw it and misunderstood...

- still...would it be possible to save the installedSecurityManager state and set things backfor every test, i.e. uninstall security Manager somehow? Would that be aslowing down things?

Myrna

[jira] Commented: (DERBY-821) Client driver: Implicitly close exhausted result sets on the server

2006-01-31 Thread Philip Wilder (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-821?page=comments#action_12364666 ] 

Philip Wilder commented on DERBY-821:
-

I'm sorry I just noticed this now Knut but I should bring it to your attention 
that you are in fact undoing work that was done in DERBY-213. The decision to 
remove the implicit close from the Client Driver ResultSets was to bring the 
Derby Client in line with the embedded driver which does not close ResultSets 
implicitly. Also there is an outstanding jira issue (DERBY-545) that asks the 
question as to what the Client should do. I would ask that if you come to a 
concrete conclusion the you also address DERBY-545 when you close this issue.

I will be monitoring DERBY-821 for a few days if you would like anything 
clarified.

 Client driver: Implicitly close exhausted result sets on the server
 ---

  Key: DERBY-821
  URL: http://issues.apache.org/jira/browse/DERBY-821
  Project: Derby
 Type: Improvement
   Components: Network Client, Network Server, Performance
 Versions: 10.2.0.0
 Reporter: Knut Anders Hatlen
 Assignee: Knut Anders Hatlen
 Priority: Minor
  Fix For: 10.2.0.0
  Attachments: DERBY-821.diff, DERBY-821.stat, changes.html

 Forward-only result sets that are exhausted should be implicitly
 closed on the server. This way, ResultSet.close() does not have to
 send an explicit close message generating unnecessary network traffic.
 The DRDA protocol supports this. From the description of OPNQRY (open
 query):
   The qryclsimp parameter controls whether the target server
   implicitly closes a non-scrollable query upon end of data (SQLSTATE
   02000) in association with the cursor type.

-- 
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

Re: [jira] Commented: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause

2006-01-31 Thread Rick Hillegas


Hi Kathey,

Sure. I'm also adjusting the casting tests in BooleanTest.java.

Regards,
-Rick

Kathey Marsden (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-887?page=comments#action_12364653 ] 


Kathey Marsden commented on DERBY-887:
--

Thanks Rick for looking at this issue.
As part of the fix,  can you add BOOLEAN to the the cast and comparison tables 
in the lang/casting.java test?

Thanks

Kathey


 


Select statement returns wrong number of rows if you compare an integer column 
with a boolean expression in the where clause


Key: DERBY-887
URL: http://issues.apache.org/jira/browse/DERBY-887
Project: Derby
   Type: Bug
 Components: SQL
   Versions: 10.2.0.0
Environment: Java : java version 1.5.0_02
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
Classpath : c:/pantry/derby.jar;c:/pantry/derbytools.jar;
OS: Windows XP Professional
   Reporter: Manjula Kutty
   Assignee: Rick Hillegas
   Priority: Critical
Fix For: 10.2.0.0
Attachments: DERBY-887.sql

I have a table with 2 columns one is BIGINT which is Generated always starting 
with 1 and increment by1 and the other one is timestamp
ij select id,date from inbox where id = 03;
ID  |DATE
---
25  |2006-01-26 14:35:46.584
34  |2006-01-26 14:36:16.588
21  |2006-01-26 14:34:46.455
22  |2006-01-26 14:34:47.176
27  |2006-01-26 14:35:47.054
24  |2006-01-26 14:35:16.58
28  |2006-01-26 14:35:47.305
35  |2006-01-26 14:36:18.771
31  |2006-01-26 14:35:48.496
32  |2006-01-26 14:35:48.887
33  |2006-01-26 14:35:49.308
11 rows selected
ij select id,date from inbox where id = true;
ID  |DATE
---
21  |2006-01-26 14:34:46.455
1 row selected
Both queries should return same number of rows
Also If I delete the first row from the table then select id,date from inbox 
where id = true; returns the second row
ij delete from inbox where id=21;
1 row inserted/updated/deleted
Then again run
ij select id ,date from inbox where id=true;
ID  |DATE
---
22 |2006-01-26 14:35:16.58
Which indicates that the select returns only the first row and then is getting 
closed

[jira] Commented: (DERBY-896) Cast date to timestamp results in ERROR 42846: Cannot convert types 'DATE' to 'TIMESTAMP'.

[ 
http://issues.apache.org/jira/browse/DERBY-896?page=comments#action_12364687 ] 

Satheesh Bandaram commented on DERBY-896:
-

I think Derby currently doesn't support this casting... The documentation is 
wrong here and is left over from OLD cloudscape product. The exact same 
paragraph is found in Cloudscape documentation.

Derby's casting system was reworked to bring it closer to standards Though 
I don't know exactly what the standards say about this particular conversion. 
Derby does support two builtin functions, time() and date() that can be used to 
extract time or date from timestamp types, as follows.

values date(current_timestamp);

I would like to mark this bug as NEW FEATURE and possibly open a documentation 
bug to remove that paragraph from documentation to reflect current Derby 
behavior. Any changes to Derby behavior could then be correctly added to 
documentation when it happens.

 Cast date to timestamp results in ERROR 42846: Cannot convert types 'DATE' 
 to 'TIMESTAMP'.
 

  Key: DERBY-896
  URL: http://issues.apache.org/jira/browse/DERBY-896
  Project: Derby
 Type: Bug
 Versions: 10.1.2.1
  Environment: - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\Programme\Derby\bin\lib\derby.jar] 10.1.2.1 - (330608)
 [D:\Programme\Derby\bin\lib\derbytools.jar] 10.1.2.1 - (330608)
 Reporter: Oleksandr Alesinskyy


 Cast date  to timestamp results in ERROR 42846: Cannot convert types 'DATE' 
 to 'TIMESTAMP'.,
 e.g. in ij:
 select cast(cast ('2006-01-01' as date) as timestamp) from sys.sysschemas;
 or
 select cast (current_date as timestamp) from bradi_dat.lpaip01;
 The similar issue exists for time (ERROR 42846: Cannot convert types 'TIME' 
 to 'TIMESTAMP'.,
 Documentation clearly states that these conversions are allowed, see table 1 
 in a description of CAST function in the Derby Reference Manual and comment 
 about Conversion of date/time values below that table (see below as well).
 Conversions of date/time values
 A date/time value can always be converted to and from a TIMESTAMP. If a DATE 
 is
 converted to a TIMESTAMP, the TIME component of the resulting TIMESTAMP is 
 always
 00:00:00. If a TIME data value is converted to a TIMESTAMP, the DATE 
 component is
 set to the value of CURRENT_DATE at the time the CAST is executed. If a 
 TIMESTAMP
 is converted to a DATE, the TIME component is silently truncated. If a 
 TIMESTAMP is
 converted to a TIME, the DATE component is silently truncated.
   

-- 
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

Re: [jira] Commented: (DERBY-855) Document optimizer overrides which were introduced in 10.2

2006-01-31 Thread Eric Radzinski

Thanks Mamta,You are correct. I'm still waiting to hear from Dan about my proposed resolutions to his questions. Dan, can I proceed with implementing my proposed resolutions to your questions? They're documented as a commented directly within derby-855."Mamta A. Satoor (JIRA)" derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-855?page=comments#action_12364658 ] Mamta A. Satoor commented on DERBY-855:---Eric, Thanks for taking care of my comments. The changes look good. Dan had couple comments too, which I don't think are not covered in your most recent changes, but maybe you are still working on it. Document optimizer overrides which were introduced in 10.2&
gt;
-- Key: DERBY-855 URL: http://issues.apache.org/jira/browse/DERBY-855 Project: Derby Type: Sub-task Components: Documentation Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assignee: Eric Radzinski Fix For: 10.2.0.0 Attachments: ctundepthoptover.html, ctunoptimzoverride.html, ctunoptimzoverride.html Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric Radzinski is working on the documentation part of the feature. This issue is to keep track of documentation changes.-- 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
__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

[jira] Commented: (DERBY-868) language specific docs need implemented

2006-01-31 Thread Jean T. Anderson (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12364693 ] 

Jean T. Anderson commented on DERBY-868:


Confusion is understandable -- and has popped up elsewhere. See DERBY-587.  
I'll add an faq to the web site.

 language specific docs need implemented
 ---

  Key: DERBY-868
  URL: http://issues.apache.org/jira/browse/DERBY-868
  Project: Derby
 Type: Improvement
   Components: Documentation
  Environment: any
 Reporter: scott hutinger
  Attachments: pt_BR_build.diff

 Derby Docs needs to implement languages other than US English somewhat 
 quickly.  Currently a document exists that should be in the build 
 environment.  If no action is taken, this seems to indicate that this is not 
 important.  I feel this is very important myself, although I only speak 
 english and a very small bit of swahili (university course instead of art) :-)
 Currently some architecture needs to be in place to allow for multiple 
 additions of languages fairly easily.  I would vote for a brute force attack 
 and add the current document today, and figure out the architecture in the 
 future.

-- 
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

[jira] Commented: (DERBY-877) zOS - with DerbyClient getDate(#) fails with IllegalArgumentException - unsupported date format - resultset.java

[ 
http://issues.apache.org/jira/browse/DERBY-877?page=comments#action_12364695 ] 

Kathey Marsden commented on DERBY-877:
--

I think I will buy deceptive, but deceptive in the way that passing the 
encoding around the way client generally does  in other places  is deceptive.  
Also I think maybe the right thing is for these classes to actually go away 
moving forward.

How about I submit this fix to provide the user some relief and then file 
another for the general encoding cleanup.  I had planned to do that anyway 
based on some things I found while investigating this issue.



 zOS - with DerbyClient getDate(#) fails with IllegalArgumentException - 
 unsupported date format - resultset.java
 

  Key: DERBY-877
  URL: http://issues.apache.org/jira/browse/DERBY-877
  Project: Derby
 Type: Bug
   Components: Network Client
 Versions: 10.1.1.0
  Environment: OS/390 with classic (IBM) jvm142
 Reporter: Myrna van Lunteren
 Assignee: Kathey Marsden
  Attachments: TestEnc.java, derby-877.diff

 The test lang/resultset.java fails with DerbyNetClient on zOS 
 because ResultSet.getDate(#) fails with an 
 java.lang.IllegalArgumentException - unsupported date format.
 This is the stack trace with 10.2 debug version (but it fails 
 with 10.1 also):
 --
 
 getBytes(dt) got exception
 Data Conversion SQLException
 FAIL -- unexpected exception: 
 java.lang.IllegalArgumentException: Unsupported date format!
 java.lang.IllegalArgumentException: Unsupported date format!
 at 
 org.apache.derby.client.am.DateTime.dateBytesToDate(DateTime.java:63)
 at 
 org.apache.derby.client.am.Cursor.getDATE(Cursor.java:400)
 at 
 org.apache.derby.client.am.Cursor.getDate(Cursor.java:712)
 at 
 org.apache.derby.client.am.ResultSet.getDate(ResultSet.java:687)
 at 
 org.apache.derbyTesting.functionTests.tests.jdbcapi.resultset.main(Unknown 
 Source)
 --
 Note: does not fail with jcc.
 Also, test lang/updatableResultSet.java failed with e.g.:
   - instead of 'Got expected exception : Illegal Conversion' :
'Got expected exception : Unsupported date format!' . 
   - instead of 'Got expected exception : Illegal Conversion' :
'Got expected exception : nanos  999 or  0' .

-- 
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

[jira] Created: (DERBY-898) setAutoCommit(false) is not working properly for local connection with ClientXADataSource

setAutoCommit(false) is not working properly for local connection with 
ClientXADataSource
-

 Key: DERBY-898
 URL: http://issues.apache.org/jira/browse/DERBY-898
 Project: Derby
Type: Bug
  Components: Network Server  
Versions: 10.1.1.0, 10.1.1.1
Reporter: Kathey Marsden
 Assigned to: Kathey Marsden 
Priority: Critical
 Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.3


 Network Server is not honoring local 
transaction rollback using ClientXADataSource.  Run the following standalone 
JDBC code.  
The output shows that after rolling back the local transaction, 
the inserted data is still present.

final org.apache.derby.jdbc.ClientXADataSource ds =
new org.apache.derby.jdbc.ClientXADataSource();
ds.setServerName(localhost);
ds.setPortNumber(1527);

ds.setDatabaseName(WOMBAT);
ds.setTraceLevel(-1);

ds.setSecurityMechanism(ds.CLEAR_TEXT_PASSWORD_SECURITY);
ds.setUser(dbuser1);
ds.setPassword(dbpwd1);
//ds.setLogWriter(new 
java.io.PrintWriter(System.out));

XAConnection xaConn = ds.getXAConnection();
Connection conn = xaConn.getConnection();


conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_R
EAD);

conn.setAutoCommit(true);

System.out.println(Database product:  + 
conn.getMetaData().getDatabaseProductName());
System.out.println(Database version:  + 
conn.getMetaData().getDatabaseProductVersion());
System.out.println(Driver name:   + 
conn.getMetaData().getDriverName());
System.out.println(Driver version:+ 
conn.getMetaData().getDriverVersion());

Statement stmt = conn.createStatement();

try { stmt.execute(drop table cmtest); }
catch (SQLException sqlX) {} // ok, didn't exist

stmt.execute(CREATE TABLE cmtest (id integer not null 
primary key, name varchar(60)));
stmt.close();

conn.setAutoCommit(false);

PreparedStatement pstmt = conn.prepareStatement(
INSERT INTO cmtest (id, name) VALUES(?,?),
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);

pstmt.setInt(1, 13);
pstmt.setString(2, blah1);
pstmt.executeUpdate();

pstmt.setInt(1, 2);
pstmt.setString(2, blah2);
pstmt.executeUpdate();

conn.rollback();

PreparedStatement pstmt2 = conn.prepareStatement(
SELECT * FROM cmtest WHERE id = ?,
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);

pstmt2.setInt(1, 13);

ResultSet rset = pstmt2.executeQuery();

if (rset.next())
{
System.out.println(Test fails. First insert was 
not rolled back.);
System.out.println(The data is still present. It 
is:  + rset.getObject(1) +
   ,  + rset.getObject(2));
}
else
System.out.println(Test passes. First insert was 
rolled back.);

Here's the output,

Database product: Apache Derby
Database version: 10.1.2.2
Driver name:  Apache Derby Network Client JDBC Driver
Driver version:   10.1.2.2
Test fails. First insert was not rolled back.
The data is still present. It is: 13, blah1

On some brief investigation I see that the Network Server embedded connection 
is  in autocomit mode so is autocommitting the transaction before the rollback. 
  Network server should always have autocommit false and let the client drive 
the commit.  



-- 
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

[jira] Created: (DERBY-899) Cannot rollback to savepoint when using ClientXADataSource

Cannot rollback to savepoint when using ClientXADataSource
--

 Key: DERBY-899
 URL: http://issues.apache.org/jira/browse/DERBY-899
 Project: Derby
Type: Bug
  Components: Network Client, Network Server  
Versions: 10.1.1.0, 10.1.1.1
Reporter: Kathey Marsden
 Fix For: 10.2.0.0



save points don't seem to be working with DerbyClient using 
XA.

levels i am on:
10.1.2.2
Apache Derby

Exception thrown is:

Exception in thread main 
org.apache.derby.client.am.SqlException: SAVEPOINT, MyPoint 
does not  exist or is not active in the current transaction.
at org.apache.derby.client.am.Statement.completeSqlca(Unknown 
Source)
at 
org.apache.derby.client.am.Statement.completeExecuteImmediate(Un
known Source)
at 
org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMrepl
y(Unknown Source)
at 
org.apache.derby.client.net.NetStatementReply.readExecuteImmedia
te(Unknown Source)
at 
org.apache.derby.client.net.StatementReply.readExecuteImmediate(
Unknown Source)
at 
org.apache.derby.client.net.NetStatement.readExecuteImmediate_(U
nknown Source)
at 
org.apache.derby.client.am.Statement.readExecuteImmediate(Unknow
n Source)
at org.apache.derby.client.am.Statement.flowExecute(Unknown 
Source)
at org.apache.derby.client.am.Statement.executeX(Unknown 
Source)
at org.apache.derby.client.am.Connection.rollback(Unknown 
Source)
at 
org.apache.derby.client.am.LogicalConnection.rollback(Unknown 
Source)
at 
Derby.networkServer.NSConnection.main(NSConnection.java:103)

Test case below 

class SavePointProblem337977  
{

public static void main (String args [])throws Exception {
//org.apache.derby.jdbc.ClientConnectionPoolDataSource ds 
= new org.apache.derby.jdbc.ClientConnectionPoolDataSource();
org.apache.derby.jdbc.ClientXADataSource ds = new 
org.apache.derby.jdbc.ClientXADataSource();

Connection conn = null;
ds.setDatabaseName(e:\\temp\\sampl127;create=true);

XAConnection xaCon = ds.getXAConnection() ;
 //PooledConnection xaCon = ds.getPooledConnection() ;
 
 
 conn = xaCon.getConnection();



DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());

Statement st = null;
PreparedStatement ps1 = null;
 try
 {
 st = conn.createStatement ();
 try
 {
st.executeUpdate (drop table TAB1);
 }catch (SQLException x)
 {
System.out.println (no table exists);
 }
 
 ps1 = conn.prepareStatement(CREATE TABLE 
TAB1(COL1 INT NOT NULL));
 ps1.executeUpdate();

 conn.commit ();
 } catch (SQLException x)
 {
 System.out.println (table already exists);
 }
 
 
 conn.setAutoCommit(false);
 conn.createStatement().execute(update tab1 set col1 = 
-1 where col1 = 9);
 Savepoint savepoint1 = conn.setSavepoint(MyPoint);

 conn.rollback(savepoint1);
}
}


-- 
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

[jira] Commented: (DERBY-855) Document optimizer overrides which were introduced in 10.2

[ 
http://issues.apache.org/jira/browse/DERBY-855?page=comments#action_12364698 ] 

Daniel John Debrunner commented on DERBY-855:
-

The suggestion for constraint was

constraint
Use the constraint property to override the index that the optimizer selects 
and force the use of a particular index or force a table scan.
To force the use of the index that enforces a primary key or unique constraint, 
use the constraint property and specify the
unqualified name of the constraint. 

I think the first sentence is not required. Some of it is duplicated in the 
second sentence, and the comment about 'force a table scan is wrong'.



 Document optimizer overrides which were introduced in 10.2
 --

  Key: DERBY-855
  URL: http://issues.apache.org/jira/browse/DERBY-855
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.2.0.0
 Reporter: Mamta A. Satoor
 Assignee: Eric Radzinski
  Fix For: 10.2.0.0
  Attachments: ctundepthoptover.html, ctunoptimzoverride.html, 
 ctunoptimzoverride.html

 Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric 
 Radzinski is working on the documentation part of the feature. This issue is 
 to keep track of documentation changes.

-- 
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

[jira] Commented: (DERBY-855) Document optimizer overrides which were introduced in 10.2

[ 
http://issues.apache.org/jira/browse/DERBY-855?page=comments#action_12364700 ] 

Daniel John Debrunner commented on DERBY-855:
-

More on the constraint, is the override limited to indexes backing unique and 
primary key constaints, or can indexes backing foreign key constraints also be 
used? I guess this is really a question against the functional spec.

 Document optimizer overrides which were introduced in 10.2
 --

  Key: DERBY-855
  URL: http://issues.apache.org/jira/browse/DERBY-855
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.2.0.0
 Reporter: Mamta A. Satoor
 Assignee: Eric Radzinski
  Fix For: 10.2.0.0
  Attachments: ctundepthoptover.html, ctunoptimzoverride.html, 
 ctunoptimzoverride.html

 Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric 
 Radzinski is working on the documentation part of the feature. This issue is 
 to keep track of documentation changes.

-- 
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

[jira] Updated: (DERBY-899) Cannot rollback to savepoint when using ClientXADataSource

 [ http://issues.apache.org/jira/browse/DERBY-899?page=all ]

Kathey Marsden updated DERBY-899:
-

Fix Version: 10.1.3.0
 10.1.2.3
Description: 
From a user using client XA.

save points don't seem to be working with DerbyClient using 
XA.

levels i am on:
10.1.2.2
Apache Derby

Exception thrown is:

Exception in thread main 
org.apache.derby.client.am.SqlException: SAVEPOINT, MyPoint 
does not  exist or is not active in the current transaction.
at org.apache.derby.client.am.Statement.completeSqlca(Unknown 
Source)
at 
org.apache.derby.client.am.Statement.completeExecuteImmediate(Un
known Source)
at 
org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMrepl
y(Unknown Source)
at 
org.apache.derby.client.net.NetStatementReply.readExecuteImmedia
te(Unknown Source)
at 
org.apache.derby.client.net.StatementReply.readExecuteImmediate(
Unknown Source)
at 
org.apache.derby.client.net.NetStatement.readExecuteImmediate_(U
nknown Source)
at 
org.apache.derby.client.am.Statement.readExecuteImmediate(Unknow
n Source)
at org.apache.derby.client.am.Statement.flowExecute(Unknown 
Source)
at org.apache.derby.client.am.Statement.executeX(Unknown 
Source)
at org.apache.derby.client.am.Connection.rollback(Unknown 
Source)
at 
org.apache.derby.client.am.LogicalConnection.rollback(Unknown 
Source)
at 
Derby.networkServer.NSConnection.main(NSConnection.java:103)

Test case below 

class SavePointProblem337977  
{

public static void main (String args [])throws Exception {
//org.apache.derby.jdbc.ClientConnectionPoolDataSource ds 
= new org.apache.derby.jdbc.ClientConnectionPoolDataSource();
org.apache.derby.jdbc.ClientXADataSource ds = new 
org.apache.derby.jdbc.ClientXADataSource();

Connection conn = null;
ds.setDatabaseName(e:\\temp\\sampl127;create=true);

XAConnection xaCon = ds.getXAConnection() ;
 //PooledConnection xaCon = ds.getPooledConnection() ;
 
 
 conn = xaCon.getConnection();



DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());

Statement st = null;
PreparedStatement ps1 = null;
 try
 {
 st = conn.createStatement ();
 try
 {
st.executeUpdate (drop table TAB1);
 }catch (SQLException x)
 {
System.out.println (no table exists);
 }
 
 ps1 = conn.prepareStatement(CREATE TABLE 
TAB1(COL1 INT NOT NULL));
 ps1.executeUpdate();

 conn.commit ();
 } catch (SQLException x)
 {
 System.out.println (table already exists);
 }
 
 
 conn.setAutoCommit(false);
 conn.createStatement().execute(update tab1 set col1 = 
-1 where col1 = 9);
 Savepoint savepoint1 = conn.setSavepoint(MyPoint);

 conn.rollback(savepoint1);
}
}


  was:

save points don't seem to be working with DerbyClient using 
XA.

levels i am on:
10.1.2.2
Apache Derby

Exception thrown is:

Exception in thread main 
org.apache.derby.client.am.SqlException: SAVEPOINT, MyPoint 
does not  exist or is not active in the current transaction.
at org.apache.derby.client.am.Statement.completeSqlca(Unknown 
Source)
at 
org.apache.derby.client.am.Statement.completeExecuteImmediate(Un
known Source)
at 
org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMrepl
y(Unknown Source)
at 
org.apache.derby.client.net.NetStatementReply.readExecuteImmedia
te(Unknown Source)
at 
org.apache.derby.client.net.StatementReply.readExecuteImmediate(
Unknown Source)
at 
org.apache.derby.client.net.NetStatement.readExecuteImmediate_(U
nknown Source)
at 
org.apache.derby.client.am.Statement.readExecuteImmediate(Unknow
n Source)
at org.apache.derby.client.am.Statement.flowExecute(Unknown 
Source)
at org.apache.derby.client.am.Statement.executeX(Unknown 
Source)
at org.apache.derby.client.am.Connection.rollback(Unknown 
Source)
at 
org.apache.derby.client.am.LogicalConnection.rollback(Unknown 
Source)
at 
Derby.networkServer.NSConnection.main(NSConnection.java:103)

Test case below 

class SavePointProblem337977  
{

public static void main (String args [])throws Exception {
//org.apache.derby.jdbc.ClientConnectionPoolDataSource ds 
= new org.apache.derby.jdbc.ClientConnectionPoolDataSource();
org.apache.derby.jdbc.ClientXADataSource ds = new 
org.apache.derby.jdbc.ClientXADataSource();

Connection conn = null;
ds.setDatabaseName(e:\\temp\\sampl127;create=true);

XAConnection xaCon =

[jira] Commented: (DERBY-877) zOS - with DerbyClient getDate(#) fails with IllegalArgumentException - unsupported date format - resultset.java

[ 
http://issues.apache.org/jira/browse/DERBY-877?page=comments#action_12364702 ] 

Daniel John Debrunner commented on DERBY-877:
-

Sounds good - fix the bug  register the cleanup issue.

 zOS - with DerbyClient getDate(#) fails with IllegalArgumentException - 
 unsupported date format - resultset.java
 

  Key: DERBY-877
  URL: http://issues.apache.org/jira/browse/DERBY-877
  Project: Derby
 Type: Bug
   Components: Network Client
 Versions: 10.1.1.0
  Environment: OS/390 with classic (IBM) jvm142
 Reporter: Myrna van Lunteren
 Assignee: Kathey Marsden
  Attachments: TestEnc.java, derby-877.diff

 The test lang/resultset.java fails with DerbyNetClient on zOS 
 because ResultSet.getDate(#) fails with an 
 java.lang.IllegalArgumentException - unsupported date format.
 This is the stack trace with 10.2 debug version (but it fails 
 with 10.1 also):
 --
 
 getBytes(dt) got exception
 Data Conversion SQLException
 FAIL -- unexpected exception: 
 java.lang.IllegalArgumentException: Unsupported date format!
 java.lang.IllegalArgumentException: Unsupported date format!
 at 
 org.apache.derby.client.am.DateTime.dateBytesToDate(DateTime.java:63)
 at 
 org.apache.derby.client.am.Cursor.getDATE(Cursor.java:400)
 at 
 org.apache.derby.client.am.Cursor.getDate(Cursor.java:712)
 at 
 org.apache.derby.client.am.ResultSet.getDate(ResultSet.java:687)
 at 
 org.apache.derbyTesting.functionTests.tests.jdbcapi.resultset.main(Unknown 
 Source)
 --
 Note: does not fail with jcc.
 Also, test lang/updatableResultSet.java failed with e.g.:
   - instead of 'Got expected exception : Illegal Conversion' :
'Got expected exception : Unsupported date format!' . 
   - instead of 'Got expected exception : Illegal Conversion' :
'Got expected exception : nanos  999 or  0' .

-- 
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

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

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

 Key: DERBY-900
 URL: http://issues.apache.org/jira/browse/DERBY-900
 Project: Derby
Type: Bug
Reporter: Daniel John Debrunner
 Fix For: 10.2.0.0


These constructors use the Java default platform encoding to convert the bytes 
to a String, this typically leads to bugs on platforms with different encodings.

Replace with code using fixed conversion, or alternative mechanisms. 
If the call is required its use should be commented as to why it is required.

org.apache.derby.client.am.ClobOutputStream - some existing bug?
org.apache.derby.client.am.DateTime - see DERBY-877
org.apache.derby.client.am.sqlca

I generated this list using the Java search in eclipse for references to the 
constructors
String(byte[])
String(byte[],int,int)



-- 
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

[jira] Updated: (DERBY-891) derby_tests.policy file contains references to csinfo and db2j - should get cleaned up

2006-01-31 Thread Myrna van Lunteren (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-891?page=all ]

Myrna van Lunteren updated DERBY-891:
-

Other Info: [Patch available]
  Priority: Trivial  (was: Minor)

 derby_tests.policy file contains references to csinfo and db2j - should get 
 cleaned up
 --

  Key: DERBY-891
  URL: http://issues.apache.org/jira/browse/DERBY-891
  Project: Derby
 Type: Bug
   Components: Test
 Versions: 10.2.0.0
 Reporter: Myrna van Lunteren
 Assignee: Myrna van Lunteren
 Priority: Trivial
  Attachments: DERBY-891_013106.diff, DERBY-891_013106.stat

 The derby_tests.policy file uses references to csinfo and db2j.
 These are left-overs from pre-contribution and rename to apache and should 
 get cleaned up.
 I suspect that the db2j references can simply be taken out, but that should 
 get double-checked.
 The csinfo references are used in jvm.java. There referenced in the 
 testing/README.htm.
 I propose to change the name of these properties as follows:
 csinfo.codejar - URL to the jar files when they are in the classpath 
  change to derby.codejar
 csinfo.codeclasses - URL to the classes directory when it is in the classpath
  change to derby.codeclasses
 csinfo.codedir - File location of either csinfo.codejar or csinfo.codejar.
  the comment said : // Only required due to a BUG.
  Need to figure out which 'BUG' that is and document better
  change to derby.codedir
 csinfo.trustedhost
  change to derby.clienthost
  document: - specifies the clients ip address/hostName. 
 csinfo.serverhost 
  change to derby.serverhost
  document: -Host name or ip where network server is started.
  

-- 
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

[jira] Created: (DERBY-901) Remove use of String(byte[]) constructors in network server leading to non-portable behaviour

Remove use of String(byte[]) constructors in network server leading to 
non-portable behaviour
-

 Key: DERBY-901
 URL: http://issues.apache.org/jira/browse/DERBY-901
 Project: Derby
Type: Bug
Reporter: Daniel John Debrunner


These constructors use the Java default platform encoding to convert the bytes 
to a String, this typically leads to bugs on platforms with different encodings.

Replace with code using fixed conversion, or alternative mechanisms. 
If the call is required its use should be commented as to why it is required.

org.apache.derby.impl.drda.DRDAConnThread

I generated this list using the Java search in eclipse for references to the 
constructors
String(byte[])
String(byte[],int,int) - no occurences found in java/drda

-- 
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

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



org.apache.derby.client.am.ClobOutputStream - some existing bug?

DERBY-683?

Myrna

[jira] Created: (DERBY-902) Remove use of String(byte[]) and String(byte[], int, int) constructors in engine leading to non-portable behaviour

Remove use of String(byte[]) and String(byte[], int, int) constructors in 
engine leading to non-portable behaviour
--

 Key: DERBY-902
 URL: http://issues.apache.org/jira/browse/DERBY-902
 Project: Derby
Type: Bug
  Components: Network Server  
Reporter: Daniel John Debrunner
 Fix For: 10.2.0.0


These constructors use the Java default platform encoding to convert the bytes 
to a String, this typically leads to bugs on platforms with different encodings.

Replace with code using fixed conversion, or alternative mechanisms. 
If the call is required its use should be commented as to why it is required.

org.apache.derby.catalog.SystemProcedures

I generated this list using the Java search in eclipse for references to the 
constructors
String(byte[])
String(byte[],int,int) - no occurrrences in java/engine

-- 
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

[jira] Created: (DERBY-903) Remove use of String(byte[]) and String(byte[], int, int) constructors in testing leading to non-portable behaviour

Remove use of String(byte[]) and String(byte[], int, int) constructors in 
testing leading to non-portable behaviour
---

 Key: DERBY-903
 URL: http://issues.apache.org/jira/browse/DERBY-903
 Project: Derby
Type: Bug
  Components: Test  
Versions: 10.2.0.0
Reporter: Daniel John Debrunner
 Fix For: 10.2.0.0


These constructors use the Java default platform encoding to convert the bytes 
to a String, this typically leads to bugs on platforms with different encodings.

Replace with code using fixed conversion, or alternative mechanisms. 
If the call is required its use should be commented as to why it is required.

org.apache.derbyTesting.functionTests.tests.jdbcapi.blobclob4BLOB
org.apache.derbyTesting.functionTests.tests.jdbcapi.resultset
org.apache.derbyTesting.functionTests.tests.lang.coalesceTests
org.apache.derbyTesting.functionTests.tests.store.streamingColumn

I generated this list using the Java search in eclipse for references to the 
constructors
String(byte[])
String(byte[],int,int) (no occurrences in java/testing)

-- 
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

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

2006-01-31 Thread Deepa Remesh (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-900?page=comments#action_12364714 ] 

Deepa Remesh commented on DERBY-900:


org.apache.derby.client.am.ClobOutputStream -  DERBY-683 is open for this

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

  Key: DERBY-900
  URL: http://issues.apache.org/jira/browse/DERBY-900
  Project: Derby
 Type: Bug
 Reporter: Daniel John Debrunner
  Fix For: 10.2.0.0


 These constructors use the Java default platform encoding to convert the 
 bytes to a String, this typically leads to bugs on platforms with different 
 encodings.
 Replace with code using fixed conversion, or alternative mechanisms. 
 If the call is required its use should be commented as to why it is required.
 org.apache.derby.client.am.ClobOutputStream - some existing bug?
 org.apache.derby.client.am.DateTime - see DERBY-877
 org.apache.derby.client.am.sqlca
 I generated this list using the Java search in eclipse for references to the 
 constructors
 String(byte[])
 String(byte[],int,int)

-- 
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

[jira] Commented: (DERBY-896) Cast date to timestamp results in ERROR 42846: Cannot convert types 'DATE' to 'TIMESTAMP'.

2006-01-31 Thread Bernt M. Johnsen (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-896?page=comments#action_12364719 ] 

Bernt M. Johnsen commented on DERBY-896:


The SQL standard (1999) states (ch. 6.22):

DATE may be cast to DATE and TIMESTAMP
TIME may be cast to TIME and TIMESTAMP
TIMESTAMP may be cast to DATE, TIME and TIMESTAMP

when DATE cast to TIMESTAMP, the time 00:00:00 is used
when TIME is cast to TIMESTAMP, current date is used

(Note: TIME/DATE/TIMESTAMP types may also be cast to CHAR/VARCHAR/CLOB and vice 
versa)

 Cast date to timestamp results in ERROR 42846: Cannot convert types 'DATE' 
 to 'TIMESTAMP'.
 

  Key: DERBY-896
  URL: http://issues.apache.org/jira/browse/DERBY-896
  Project: Derby
 Type: Bug
 Versions: 10.1.2.1
  Environment: - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\Programme\Derby\bin\lib\derby.jar] 10.1.2.1 - (330608)
 [D:\Programme\Derby\bin\lib\derbytools.jar] 10.1.2.1 - (330608)
 Reporter: Oleksandr Alesinskyy


 Cast date  to timestamp results in ERROR 42846: Cannot convert types 'DATE' 
 to 'TIMESTAMP'.,
 e.g. in ij:
 select cast(cast ('2006-01-01' as date) as timestamp) from sys.sysschemas;
 or
 select cast (current_date as timestamp) from bradi_dat.lpaip01;
 The similar issue exists for time (ERROR 42846: Cannot convert types 'TIME' 
 to 'TIMESTAMP'.,
 Documentation clearly states that these conversions are allowed, see table 1 
 in a description of CAST function in the Derby Reference Manual and comment 
 about Conversion of date/time values below that table (see below as well).
 Conversions of date/time values
 A date/time value can always be converted to and from a TIMESTAMP. If a DATE 
 is
 converted to a TIMESTAMP, the TIME component of the resulting TIMESTAMP is 
 always
 00:00:00. If a TIME data value is converted to a TIMESTAMP, the DATE 
 component is
 set to the value of CURRENT_DATE at the time the CAST is executed. If a 
 TIMESTAMP
 is converted to a DATE, the TIME component is silently truncated. If a 
 TIMESTAMP is
 converted to a TIME, the DATE component is silently truncated.
   

-- 
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

[jira] Commented: (DERBY-855) Document optimizer overrides which were introduced in 10.2

[ 
http://issues.apache.org/jira/browse/DERBY-855?page=comments#action_12364723 ] 

Satheesh Bandaram commented on DERBY-855:
-

I think the contraint override can be used for foreign key constraints as 
well... I tried this:

 create table prim ( i int not null primary key, j int);
 create table sec (i int, constraint fk foreign key(i) references prim(i), j 
int);

 select * from sec --derby-properties constraint=fk
 ;

...
optimizer estimated cost:  136.34

User supplied optimizer overrides on SEC are { 
index=SQL060131012414010}   =
Index Scan ResultSet for SEC using constraint FK at read committed 
isolation level using instantaneous share row locking chosen by the optimizer
Number of opens = 1

 Document optimizer overrides which were introduced in 10.2
 --

  Key: DERBY-855
  URL: http://issues.apache.org/jira/browse/DERBY-855
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.2.0.0
 Reporter: Mamta A. Satoor
 Assignee: Eric Radzinski
  Fix For: 10.2.0.0
  Attachments: ctundepthoptover.html, ctunoptimzoverride.html, 
 ctunoptimzoverride.html

 Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric 
 Radzinski is working on the documentation part of the feature. This issue is 
 to keep track of documentation changes.

-- 
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

Re: Features of the JUnit test execution harness

On 1/24/06, Kristian Waagan [EMAIL PROTECTED] wrote:
Kristian Waagan wrote:4) Should it be possible to run single JUnit test/suite from the
command line
2 yeahs snipped, 3rd: (Dan:)
 I think it's essential that a single test can be run. I don't think it's essential that it is from test's main method. The harness produces the useful functionality of setting up the correct environment for the test,
 not sure if that could be duplicated in evey main method for every test.Good point Dan.Citing Dan: ...harness produces the useful functionality of setting upthe correct environment for the test,
Can somebody please explain to me what is actually done by the harness?I did have a quick look at the harness code, but I would need to studyit a bit more to understand what it actually does. Stating what the
harness does when it comes to setting up the environment for tests wouldbe good for the general understanding of the test execution process.
---

I've had this messages 'starred' in gmail for a bit, sorry for replying only now. There's no quick way to describe what the 'functiontest' harness does - I've tried to describe what I understand in the past (see the java/testing/README.htm)...


Maybe if you have specific questions I'll be able to answer better.

The main thing I think that the functiontest harness does is set up all sorts of fun properties for the tests to use, sothe same test can run in a number of different ways - in a suite, by itself, with different encryption algorithms, with encoding, locales, frameworks, with
java.sql.DriverManager or instead with DataSource; to run in sequence or separately, start a new database or not...Depending on these properties, more or less 'magic' is done - for example, network server gets started or not, files needed for the test get copied around...

Properties in a suite override properties set for individual tests lower level.
Also, it is able to figure out what jvm is used and add specific (non-standard)properties as needed or applicable.

A big part of it is to control, and eliminate uninteresting differences in the output, but that would be irrelevant with Junit, yes?

Does this help at all?
But maybe that wasn't what Dan meant?

Myrna

Re: Features of the JUnit test execution harness

Silly question(s):
with the Junit testsij is not used?
if not, and we're going to convert all tests to junit, should there be a new test to test the tool ij specifically (at some point) ?
Myrna

[jira] Resolved: (DERBY-895) Post derby jars to Maven repository

2006-01-31 Thread Andrew McIntyre (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-895?page=all ]
 
Andrew McIntyre resolved DERBY-895:
---

Fix Version: 10.1.2.1
 Resolution: Fixed
  Assign To: Andrew McIntyre

Derby 10.1.2.1 jars posted to www.apache.org/dist/java-repository. Verified 
replication to ibiblio.org.

 Post derby jars to Maven repository
 ---

  Key: DERBY-895
  URL: http://issues.apache.org/jira/browse/DERBY-895
  Project: Derby
 Type: Wish
   Components: Build tools
 Versions: 10.0.2.0
 Reporter: Craig McClanahan
 Assignee: Andrew McIntyre
 Priority: Minor
  Fix For: 10.1.2.1


 Please post a copy of the JAR files from the latest Derby official release to 
 the Apache Maven1 repository (http://www.apache.org/dist/java-repository), 
 from which it gets mirrored to several other places (including 
 http://www.ibiblio.org/maven/).  This will make it easy for projects to 
 declare dependencies on Derby, and automatically download new versions as 
 they become available.

-- 
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

Re: Features of the JUnit test execution harness

2006-01-31 Thread Rick Hillegas


Hi Myrna,

I don't think we've discussed yet how or when we would convert existing 
tests to JUnit. I agree that ij needs to continue to be tested.


Regards,
-Rick

Myrna van Lunteren wrote:


Silly question(s):
with the Junit tests ij is not used?
if not, and we're going to convert all tests to junit, should there be 
a new test to test the tool ij specifically (at some point) ?


Myrna

[jira] Commented: (DERBY-895) Post derby jars to Maven repository

[ 
http://issues.apache.org/jira/browse/DERBY-895?page=comments#action_12364746 ] 

Kathey Marsden commented on DERBY-895:
--

Thanks Andrew.  Can you make sure the Release Instructions get updated?


 Post derby jars to Maven repository
 ---

  Key: DERBY-895
  URL: http://issues.apache.org/jira/browse/DERBY-895
  Project: Derby
 Type: Wish
   Components: Build tools
 Versions: 10.0.2.0
 Reporter: Craig McClanahan
 Assignee: Andrew McIntyre
 Priority: Minor
  Fix For: 10.1.2.1


 Please post a copy of the JAR files from the latest Derby official release to 
 the Apache Maven1 repository (http://www.apache.org/dist/java-repository), 
 from which it gets mirrored to several other places (including 
 http://www.ibiblio.org/maven/).  This will make it easy for projects to 
 declare dependencies on Derby, and automatically download new versions as 
 they become available.

-- 
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

Re: Features of the JUnit test execution harness

2006-01-31 Thread Kristian Waagan


Myrna van Lunteren wrote:

On 1/24/06, *Kristian Waagan* [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Kristian Waagan wrote:
4) Should it be possible to run single JUnit test/suite from the
command line

2 yeahs snipped, 3rd: (Dan:)
 I think it's essential that a single test can be run. I don't think 
it's

 essential that it is from test's main method. The harness produces the
 useful functionality of setting up the correct environment for the 
test,
 not sure if that could be duplicated in evey main method for every 
test.


Good point Dan.

Citing Dan: ...harness produces the useful functionality of setting up
the correct environment for the test,

Can somebody please explain to me what is actually done by the harness?

I did have a quick look at the harness code, but I would need to study
it a bit more to understand what it actually does. Stating what the
harness does when it comes to setting up the environment for tests would
be good for the general understanding of the test execution process.
---
 
I've had this messages 'starred' in gmail for a bit, sorry for 
replying only now. There's no quick way to describe what the 
'functiontest' harness does - I've tried to describe what I understand 
in the past (see the java/testing/README.htm)...
 
Maybe if you have specific questions I'll be able to answer better.
 
The main thing I think that the functiontest harness does is set up 
all sorts of fun properties for the tests to use, so the same test can 
run in a number of different ways - in a suite, by itself, with 
different encryption algorithms, with encoding, locales, frameworks, 
with  java.sql.DriverManager or instead with DataSource; to run in 
sequence or separately, start a new database or not...Depending on 
these properties, more or less 'magic' is done - for example, network 
server gets started or not, files needed for the test get copied 
around...
Properties in a suite override properties set for individual tests 
lower level.
Also, it is able to figure out what jvm is used and add specific 
(non-standard) properties as needed or applicable.
 
A big part of it is to control, and eliminate uninteresting 
differences in the output, but that would be irrelevant with Junit, yes?



Differences in output should be irrelevant. Although not what you 
mentioned above, the issue of (execution) control is very relevant. The 
logic for running the tests multiple times, each time with a different 
setup/environment must be located somewhere. I think Andreas' proposal 
of introducing a separate JUnit test type (see 
http://www.nabble.com/running-JUnit-tests-t887682.html#a2300670) makes 
sense, as it gives us more freedom w.r.t. handling of JUnit tests.


 
Does this help at all?

But maybe that wasn't what Dan meant?
 
Myrna



Thanks for the answer Myrna. And good work on the readme! I just skimmed 
through it now, but I will take the time to read it thoroughly soon.  
Right now I feel that it is very hard to start writing a new JUnit 
harness, since the old harness seem to contain a lot of functionality 
and magic. I wonder if it would be best to just start 
converting/writing some tests and create a framework along the way.


The above approach would probably result in several major rewritings of 
the new framework and the existing JUnit tests, but it might be better 
than thinking out everything at once (that's hard!). Perhaps I will 
rewrite an old test I have been working a little on, and put it out for 
review and comments, unless someone else beats me to it ;)




--
Kristian

[jira] Commented: (DERBY-855) Document optimizer overrides which were introduced in 10.2

[ 
http://issues.apache.org/jira/browse/DERBY-855?page=comments#action_12364747 ] 

Daniel John Debrunner commented on DERBY-855:
-

Looks like some improvements could be made in the run time statistics output, 
Satheesh's query said 

constraint=fk 

and the override info was

index=SQL060131012414010

The next line did contain the foreign key name though.

 Document optimizer overrides which were introduced in 10.2
 --

  Key: DERBY-855
  URL: http://issues.apache.org/jira/browse/DERBY-855
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.2.0.0
 Reporter: Mamta A. Satoor
 Assignee: Eric Radzinski
  Fix For: 10.2.0.0
  Attachments: ctundepthoptover.html, ctunoptimzoverride.html, 
 ctunoptimzoverride.html

 Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric 
 Radzinski is working on the documentation part of the feature. This issue is 
 to keep track of documentation changes.

-- 
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

[jira] Updated: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.

2006-01-31 Thread Suresh Thalamati (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-239?page=all ]

Suresh Thalamati updated DERBY-239:
---

Attachment: onlinebackup2.html

minor updated to the spec.  Changed the names of the new procedures to :
SYSCS_BACKUP_DATABASE_NOWAIT
SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT

 Need a online backup feature  that does not block update operations   when 
 online backup is in progress.
 

  Key: DERBY-239
  URL: http://issues.apache.org/jira/browse/DERBY-239
  Project: Derby
 Type: New Feature
   Components: Store
 Versions: 10.1.1.0
 Reporter: Suresh Thalamati
 Assignee: Suresh Thalamati
  Attachments: obtest_customer.jar, onlinebackup.html, onlinebackup1.html, 
 onlinebackup2.html, onlinebackup_1.diff, onlinebackup_2.diff, 
 onlinebackup_3.diff, onlinebackup_4.diff, onlinebackup_5.diff, 
 onlinebackup_6.diff, onlinebackup_7.diff, onlinebackup_8.diff

 Currently Derby allows users to perfoms  online backups using 
 SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure,  but while the backup is in 
 progress, update operations are temporarily blocked, but read operations can 
 still proceed.
 Blocking update operations can be real issue specifically in client server 
 environments, because user requests will be blocked for a long time if a 
 backup is in the progress on the server.

-- 
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

[jira] Resolved: (DERBY-599) Using setBlob interface, should not materialize the entire blob value into memory.

2006-01-31 Thread Sunitha Kambhampati (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-599?page=all ]
 
Sunitha Kambhampati resolved DERBY-599:
---

Resolution: Fixed

Fix has been committed.  I verified by running the test 
largedata/LobLimits.java successfully. 

 Using setBlob interface, should not materialize the entire blob value into 
 memory.
 --

  Key: DERBY-599
  URL: http://issues.apache.org/jira/browse/DERBY-599
  Project: Derby
 Type: Bug
   Components: JDBC
 Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
  Environment: all
 Reporter: Sunitha Kambhampati
 Assignee: Sunitha Kambhampati
  Fix For: 10.2.0.0
  Attachments: Derby599.diff.txt, Derby599.stat.txt

 setBlob and blob.length() calls should not materialize blob into memory.

-- 
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

[jira] Closed: (DERBY-599) Using setBlob interface, should not materialize the entire blob value into memory.

2006-01-31 Thread Sunitha Kambhampati (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-599?page=all ]
 
Sunitha Kambhampati closed DERBY-599:
-


 Using setBlob interface, should not materialize the entire blob value into 
 memory.
 --

  Key: DERBY-599
  URL: http://issues.apache.org/jira/browse/DERBY-599
  Project: Derby
 Type: Bug
   Components: JDBC
 Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
  Environment: all
 Reporter: Sunitha Kambhampati
 Assignee: Sunitha Kambhampati
  Fix For: 10.2.0.0
  Attachments: Derby599.diff.txt, Derby599.stat.txt

 setBlob and blob.length() calls should not materialize blob into memory.

-- 
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

[jira] Created: (DERBY-904) big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific

big decimal error diff in derbyall lang/procedure test run in the 
DerbyNetClient - jdk1.3 specific
--

 Key: DERBY-904
 URL: http://issues.apache.org/jira/browse/DERBY-904
 Project: Derby
Type: Bug
  Components: Regression Test Failure  
Versions: 10.1.2.2
 Environment: sun jdk1.3.1
Reporter: Mike Matrigali
Priority: Critical


derby all regression test failure in the following test.  Most recently it 
failed in the 1/27 derby build.  It also failed on 1/20.  It ran fine on 1/13.  
Have
not had time to narrow down further.  Did note that there is a separate master 
for this test , but no jdk131 specific masters that I could see.

*** Start: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
2006-01-22 05:30:23 ***
274 del
 EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow 
occurred during numeric data type conversion of 10243.. See attached 
Throwable.
274a274
 EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow 
 occurred during numeric data type conversion of 10243.. See attached 
 Throwable. Caused by exception class 
 org.apache.derby.client.am.ConversionException: [converters] Overflow 
 occurred during numeric data type conversion of 10243.
337 del
 EXPECTED SQL Exception: Invalid argument: parameter index 2 is not an OUT or 
INOUT parameter.
337a337
 EXPECTED SQL Exception: XN009.S : [0] 2
355 del
 EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow 
occurred during numeric data type conversion of 102.33.. See attached 
Throwable.
355a355
 EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow 
 occurred during numeric data type conversion of 102.33.. See attached 
 Throwable. Caused by exception class 
 org.apache.derby.client.am.ConversionException: [converters] Overflow 
 occurred during numeric data type conversion of 102.33.
Test Failed.
*** End:   procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
2006-01-22 05:31:39 ***


-- 
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

[jira] Updated: (DERBY-904) big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific

 [ http://issues.apache.org/jira/browse/DERBY-904?page=all ]

Mike Matrigali updated DERBY-904:
-

Component: Regression Test Failure
  Version: 10.1.2.2

 big decimal error diff in derbyall lang/procedure test run in the 
 DerbyNetClient - jdk1.3 specific
 --

  Key: DERBY-904
  URL: http://issues.apache.org/jira/browse/DERBY-904
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.1.2.2
  Environment: sun jdk1.3.1
 Reporter: Mike Matrigali
 Priority: Critical


 derby all regression test failure in the following test.  Most recently it 
 failed in the 1/27 derby build.  It also failed on 1/20.  It ran fine on 
 1/13.  Have
 not had time to narrow down further.  Did note that there is a separate 
 master for this test , but no jdk131 specific masters that I could see.
 *** Start: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:30:23 ***
 274 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 10243.. See 
 attached Throwable.
 274a274
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 10243.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 10243.
 337 del
  EXPECTED SQL Exception: Invalid argument: parameter index 2 is not an OUT 
 or INOUT parameter.
 337a337
  EXPECTED SQL Exception: XN009.S : [0] 2
 355 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 102.33.. See 
 attached Throwable.
 355a355
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 102.33.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 102.33.
 Test Failed.
 *** End:   procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:31:39 ***

-- 
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

[jira] Commented: (DERBY-896) Cast date to timestamp results in ERROR 42846: Cannot convert types 'DATE' to 'TIMESTAMP'.

2006-01-31 Thread Oleksandr Alesinskyy (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-896?page=comments#action_12364754 ] 

Oleksandr Alesinskyy commented on DERBY-896:


Casting from TIMESTAMP to DATE (as well as to TIME) is supported by Derby by 
means of normal CAST function, so built-in DATE(TIMESTAMP) and TIME(TIMESTAMP) 
are superflous (but probably have to be maintained for backward compatibility).

e.g. 
 CAST(current_timestamp as date) works
 CAST(current_date as timestamp) does NOT work 

 Cast date to timestamp results in ERROR 42846: Cannot convert types 'DATE' 
 to 'TIMESTAMP'.
 

  Key: DERBY-896
  URL: http://issues.apache.org/jira/browse/DERBY-896
  Project: Derby
 Type: Bug
 Versions: 10.1.2.1
  Environment: - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [D:\Programme\Derby\bin\lib\derby.jar] 10.1.2.1 - (330608)
 [D:\Programme\Derby\bin\lib\derbytools.jar] 10.1.2.1 - (330608)
 Reporter: Oleksandr Alesinskyy


 Cast date  to timestamp results in ERROR 42846: Cannot convert types 'DATE' 
 to 'TIMESTAMP'.,
 e.g. in ij:
 select cast(cast ('2006-01-01' as date) as timestamp) from sys.sysschemas;
 or
 select cast (current_date as timestamp) from bradi_dat.lpaip01;
 The similar issue exists for time (ERROR 42846: Cannot convert types 'TIME' 
 to 'TIMESTAMP'.,
 Documentation clearly states that these conversions are allowed, see table 1 
 in a description of CAST function in the Derby Reference Manual and comment 
 about Conversion of date/time values below that table (see below as well).
 Conversions of date/time values
 A date/time value can always be converted to and from a TIMESTAMP. If a DATE 
 is
 converted to a TIMESTAMP, the TIME component of the resulting TIMESTAMP is 
 always
 00:00:00. If a TIME data value is converted to a TIMESTAMP, the DATE 
 component is
 set to the value of CURRENT_DATE at the time the CAST is executed. If a 
 TIMESTAMP
 is converted to a DATE, the TIME component is silently truncated. If a 
 TIMESTAMP is
 converted to a TIME, the DATE component is silently truncated.
   

-- 
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

[jira] Created: (DERBY-905) derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 specific

derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 
specific
--

 Key: DERBY-905
 URL: http://issues.apache.org/jira/browse/DERBY-905
 Project: Derby
Type: Bug
  Components: Regression Test Failure  
Versions: 10.1.2.2
 Environment: sun jdk1.3.1_15
Reporter: Mike Matrigali


The following nightly regression happened in the 1/27 codeline, it also failed 
on 1/20 but worked on 1/13.

*** Start: LOBTest jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 2006-01-29 
05:59:59 ***
48 del
   1 getDate  -   EXCEPTION (Invalid data 
conversion: Parameter instance 101is invalid for requested conversion 
to java.sql.Date.)
48a48
   1 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Date. Caused by exception class 
 java.lang.IllegalArgumentException: null)
56 del
   1 getTime  -   EXCEPTION (Invalid data 
conversion: Parameter instance 101is invalid for requested conversion 
to java.sql.Time.)
57 del
   1 getTimeStamp -   EXCEPTION (Invalid data 
conversion: Parameter instance 101is invalid for requested conversion 
to java.sql.Timestamp.)
57a56,57
   1 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Time. Caused by exception class 
 java.lang.IllegalArgumentException: null)
   1 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Timestamp. Caused by exception class 
 java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
 hh:mm:ss.f)
71 del
   2 getDate  -   EXCEPTION (Invalid data 
conversion: Parameter instance 102 is invalid for requested conversion to 
java.sql.Date.)
71a71
   2 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Date. Caused by exception class java.lang.IllegalArgumentException: 
 null)
79 del
   2 getTime  -   EXCEPTION (Invalid data 
conversion: Parameter instance 102 is invalid for requested conversion to 
java.sql.Time.)
80 del
   2 getTimeStamp -   EXCEPTION (Invalid data 
conversion: Parameter instance 102 is invalid for requested conversion to 
java.sql.Timestamp.)
80a79,80
   2 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Time. Caused by exception class java.lang.IllegalArgumentException: 
 null)
   2 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Timestamp. Caused by exception class 
 java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
 hh:mm:ss.f)
94 del
   3 getDate  -   EXCEPTION (Invalid data 
conversion: Parameter instance 103 is invalid for requested conversion to 
java.sql.Date.)
94a94
   3 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Date. Caused by exception class java.lang.IllegalArgumentException: 
 null)
102 del
   3 getTime  -   EXCEPTION (Invalid data 
conversion: Parameter instance 103 is invalid for requested conversion to 
java.sql.Time.)
103 del
   3 getTimeStamp -   EXCEPTION (Invalid data 
conversion: Parameter instance 103 is invalid for requested conversion to 
java.sql.Timestamp.)
103a102,103
   3 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Time. Caused by exception class java.lang.IllegalArgumentException: 
 null)
   3 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Timestamp. Caused by exception class 
 java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
 hh:mm:ss.f)
610 del
   1 getDate  -   EXCEPTION (Invalid data 
conversion: Parameter instance 101is invalid for requested conversion 
to java.sql.Date.)
610a610
   1 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Date. Caused by exception class 
 java.lang.IllegalArgumentException: null)
618 del
   1 getTime  -

[jira] Created: (DERBY-906) parameterMapping test in DerbyAll nightly regression under DerbyNetClient, specific to jdk1.3.1

parameterMapping test in DerbyAll nightly regression under DerbyNetClient, 
specific to jdk1.3.1
---

 Key: DERBY-906
 URL: http://issues.apache.org/jira/browse/DERBY-906
 Project: Derby
Type: Bug
  Components: Regression Test Failure  
Versions: 10.1.2.2
 Environment: sun jdk1.3.1_15
Reporter: Mike Matrigali
Priority: Critical


The following regression test  failed on 1/27 and 1/20, but did not fail on 
1/13.
It looks to be specific to jdk1.3.1_15 - have not seen errors in 1.4 or 1.5 
runs.

*** Start: parameterMapping jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 
2006-01-29 06:01:00 ***
1257 del
   getDate= (?):Invalid data conversion: Parameter instance 32 
  is invalid for requested 
conversion to java.sql.Date. JDBC FAIL CHAR(60)
1258 del
   getTime= (?):Invalid data conversion: Parameter instance 32 
  is invalid for requested 
conversion to java.sql.Time. JDBC FAIL CHAR(60)
1259 del
   getTimestamp= (?):Invalid data conversion: Parameter instance 32
   is invalid for requested 
conversion to java.sql.Timestamp. JDBC FAIL CHAR(60)
1259a1257,1259
   getDate= (?):Invalid data conversion: Parameter instance 32 
   is invalid for requested 
 conversion to java.sql.Date. Caused by exception class 
 java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
   getTime= (?):Invalid data conversion: Parameter instance 32 
   is invalid for requested 
 conversion to java.sql.Time. Caused by exception class 
 java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
   getTimestamp= (?):Invalid data conversion: Parameter instance 32
is invalid for requested 
 conversion to java.sql.Timestamp. Caused by exception class 
 java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
 hh:mm:ss.f JDBC FAIL CHAR(60)
1429 del
   getDate= (?):Invalid data conversion: Parameter instance 32 is invalid 
for requested conversion to java.sql.Date. JDBC FAIL VARCHAR(60)
1430 del
   getTime= (?):Invalid data conversion: Parameter instance 32 is invalid 
for requested conversion to java.sql.Time. JDBC FAIL VARCHAR(60)
1431 del
   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
invalid for requested conversion to java.sql.Timestamp. JDBC FAIL VARCHAR(60)
1431a1429,1431
   getDate= (?):Invalid data conversion: Parameter instance 32 is invalid 
 for requested conversion to java.sql.Date. Caused by exception class 
 java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
   getTime= (?):Invalid data conversion: Parameter instance 32 is invalid 
 for requested conversion to java.sql.Time. Caused by exception class 
 java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Timestamp. Caused by exception 
 class java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
 hh:mm:ss.f JDBC FAIL VARCHAR(60)
1601 del
   getDate= (?):Invalid data conversion: Parameter instance 32 is invalid 
for requested conversion to java.sql.Date. JDBC FAIL LONG VARCHAR
1602 del
   getTime= (?):Invalid data conversion: Parameter instance 32 is invalid 
for requested conversion to java.sql.Time. JDBC FAIL LONG VARCHAR
1603 del
   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
invalid for requested conversion to java.sql.Timestamp. JDBC FAIL LONG VARCHAR
1603a1601,1603
   getDate= (?):Invalid data conversion: Parameter instance 32 is invalid 
 for requested conversion to java.sql.Date. Caused by exception class 
 java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
   getTime= (?):Invalid data conversion: Parameter instance 32 is invalid 
 for requested conversion to java.sql.Time. Caused by exception class 
 java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Timestamp. Caused by exception 
 class java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
 hh:mm:ss.f JDBC FAIL LONG VARCHAR
Test Failed.
*** End:   parameterMapping jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 
2006-01-29 06:03:35 ***


-- 
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:

Re: [jira] Updated: (DERBY-904) big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific

2006-01-31 Thread Satheesh Bandaram

Anyone know what could have caused this difference? I am hoping to
assign owners for Regression Test Failures as soon as possible. David,
could this be result of your changes or any related changes to Derby
client?

Satheesh

Mike Matrigali (JIRA) wrote:

[ http://issues.apache.org/jira/browse/DERBY-904?page=all ]

Mike Matrigali updated DERBY-904:
-

Component: Regression Test Failure
Version: 10.1.2.2

big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific
--

Key: DERBY-904
URL: http://issues.apache.org/jira/browse/DERBY-904
Project: Derby
Type: Bug
Components: Regression Test Failure
Versions: 10.1.2.2
Environment: sun jdk1.3.1
Reporter: Mike Matrigali
Priority: Critical

derby all regression test failure in the following test. Most recently it failed in the 1/27 derby build. It also failed on 1/20. It ran fine on 1/13. Have
not had time to narrow down further. Did note that there is a separate master for this test , but no jdk131 specific masters that I could see.
*** Start: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 2006-01-22 05:30:23 ***
274 del
EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of "10243".. See attached Throwable.
274a274

EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of "10243".. See attached Throwable. Caused by exception class org.apache.derby.client.am.ConversionException: [converters] Overflow occurred during numeric data type conversion of "10243".

337 del
EXPECTED SQL Exception: Invalid argument: parameter index 2 is not an OUT or INOUT parameter.
337a337

EXPECTED SQL Exception: XN009.S : [0] 2

355 del
EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of "102.33".. See attached Throwable.
355a355

EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of "102.33".. See attached Throwable. Caused by exception class org.apache.derby.client.am.ConversionException: [converters] Overflow occurred during numeric data type conversion of "102.33".

Test Failed.
*** End: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 2006-01-22 05:31:39 ***

[jira] Updated: (DERBY-904) big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific

 [ http://issues.apache.org/jira/browse/DERBY-904?page=all ]

Mike Matrigali updated DERBY-904:
-

Version: 10.2.0.0
 (was: 10.1.2.2)

 big decimal error diff in derbyall lang/procedure test run in the 
 DerbyNetClient - jdk1.3 specific
 --

  Key: DERBY-904
  URL: http://issues.apache.org/jira/browse/DERBY-904
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.2.0.0
  Environment: sun jdk1.3.1
 Reporter: Mike Matrigali
 Priority: Critical


 derby all regression test failure in the following test.  Most recently it 
 failed in the 1/27 derby build.  It also failed on 1/20.  It ran fine on 
 1/13.  Have
 not had time to narrow down further.  Did note that there is a separate 
 master for this test , but no jdk131 specific masters that I could see.
 *** Start: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:30:23 ***
 274 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 10243.. See 
 attached Throwable.
 274a274
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 10243.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 10243.
 337 del
  EXPECTED SQL Exception: Invalid argument: parameter index 2 is not an OUT 
 or INOUT parameter.
 337a337
  EXPECTED SQL Exception: XN009.S : [0] 2
 355 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 102.33.. See 
 attached Throwable.
 355a355
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 102.33.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 102.33.
 Test Failed.
 *** End:   procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:31:39 ***

-- 
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

[jira] Updated: (DERBY-905) derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 specific

 [ http://issues.apache.org/jira/browse/DERBY-905?page=all ]

Mike Matrigali updated DERBY-905:
-

Fix Version: 10.2.0.0

 derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 
 specific
 --

  Key: DERBY-905
  URL: http://issues.apache.org/jira/browse/DERBY-905
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.1.2.2
  Environment: sun jdk1.3.1_15
 Reporter: Mike Matrigali
  Fix For: 10.2.0.0


 The following nightly regression happened in the 1/27 codeline, it also 
 failed on 1/20 but worked on 1/13.
 *** Start: LOBTest jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 2006-01-29 
 05:59:59 ***
 48 del
  1 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Date.)
 48a48
  1 getDate  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 101is invalid for requested 
  conversion to java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null)
 56 del
  1 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Time.)
 57 del
  1 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Timestamp.)
 57a56,57
  1 getTime  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 101is invalid for requested 
  conversion to java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null)
  1 getTimeStamp -   EXCEPTION (Invalid data 
  conversion: Parameter instance 101is invalid for requested 
  conversion to java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f)
 71 del
  2 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Date.)
 71a71
  2 getDate  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 102 is invalid for requested conversion to 
  java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null)
 79 del
  2 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Time.)
 80 del
  2 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Timestamp.)
 80a79,80
  2 getTime  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 102 is invalid for requested conversion to 
  java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null)
  2 getTimeStamp -   EXCEPTION (Invalid data 
  conversion: Parameter instance 102 is invalid for requested conversion to 
  java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f)
 94 del
  3 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Date.)
 94a94
  3 getDate  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 103 is invalid for requested conversion to 
  java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null)
 102 del
  3 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Time.)
 103 del
  3 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Timestamp.)
 103a102,103
  3 getTime  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 103 is invalid for requested conversion to 
  java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null)
  3 getTimeStamp -   EXCEPTION (Invalid data 
  conversion: Parameter instance 103 is invalid for requested conversion to 
  java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f)
 610 del
  1 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Date.)
 610a610
  1 getDate  -   EXCEPTION

[jira] Updated: (DERBY-906) parameterMapping test in DerbyAll nightly regression under DerbyNetClient, specific to jdk1.3.1

 [ http://issues.apache.org/jira/browse/DERBY-906?page=all ]

Mike Matrigali updated DERBY-906:
-

Fix Version: 10.2.0.0

 parameterMapping test in DerbyAll nightly regression under DerbyNetClient, 
 specific to jdk1.3.1
 ---

  Key: DERBY-906
  URL: http://issues.apache.org/jira/browse/DERBY-906
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.1.2.2
  Environment: sun jdk1.3.1_15
 Reporter: Mike Matrigali
 Priority: Critical
  Fix For: 10.2.0.0


 The following regression test  failed on 1/27 and 1/20, but did not fail on 
 1/13.
 It looks to be specific to jdk1.3.1_15 - have not seen errors in 1.4 or 1.5 
 runs.
 *** Start: parameterMapping jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 
 2006-01-29 06:01:00 ***
 1257 del
getDate= (?):Invalid data conversion: Parameter instance 32   
 is invalid for requested 
 conversion to java.sql.Date. JDBC FAIL CHAR(60)
 1258 del
getTime= (?):Invalid data conversion: Parameter instance 32   
 is invalid for requested 
 conversion to java.sql.Time. JDBC FAIL CHAR(60)
 1259 del
getTimestamp= (?):Invalid data conversion: Parameter instance 32  
  is invalid for requested 
 conversion to java.sql.Timestamp. JDBC FAIL CHAR(60)
 1259a1257,1259
getDate= (?):Invalid data conversion: Parameter instance 32   
  is invalid for requested 
  conversion to java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
getTime= (?):Invalid data conversion: Parameter instance 32   
  is invalid for requested 
  conversion to java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
getTimestamp= (?):Invalid data conversion: Parameter instance 32  
   is invalid for 
  requested conversion to java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f JDBC FAIL CHAR(60)
 1429 del
getDate= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Date. JDBC FAIL VARCHAR(60)
 1430 del
getTime= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Time. JDBC FAIL VARCHAR(60)
 1431 del
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Timestamp. JDBC FAIL VARCHAR(60)
 1431a1429,1431
getDate= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Date. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
getTime= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Time. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Timestamp. Caused by exception 
  class java.lang.IllegalArgumentException: Timestamp format must be 
  -mm-dd hh:mm:ss.f JDBC FAIL VARCHAR(60)
 1601 del
getDate= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Date. JDBC FAIL LONG VARCHAR
 1602 del
getTime= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Time. JDBC FAIL LONG VARCHAR
 1603 del
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Timestamp. JDBC FAIL LONG VARCHAR
 1603a1601,1603
getDate= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Date. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
getTime= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Time. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Timestamp. Caused by exception 
  class java.lang.IllegalArgumentException: Timestamp format must be 
  -mm-dd hh:mm:ss.f JDBC FAIL LONG VARCHAR
 Test Failed.
 *** End:   parameterMapping jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi

Re: Server and client compatibility test for 10.2 and 10.1

2006-01-31 Thread Dag H. Wanvik


Hi Kathey,

 Kathey == Kathey Marsden [EMAIL PROTECTED] wrote:

Kathey Server: 10.1, Client: 10.2, derbyTesting.jar: 10.1
Kathey -
Kathey jvms: jdk15, ibm142
Kathey 
Kathey  Test failures:
Kathey 
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/dbMetaDataJdbc30.java
Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadata.java
Kathey 
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/odbc_metadata.java
Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
Kathey 
derbynetclientmats/derbynetmats/derbynetmats.fail:lang/updatableResultSet.java
Kathey 
derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
Kathey derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
Kathey 
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
Kathey 
derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java

snip

Kathey - forupdate and updatableResultSet are  probably expected but it would
Kathey be good if someone familiar with the updateable resultset work on 10.2 
Kathey could verify.

I'll have a look at this.

Dag

[jira] Commented: (DERBY-904) big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific

[ 
http://issues.apache.org/jira/browse/DERBY-904?page=comments#action_12364760 ] 

David Van Couvering commented on DERBY-904:
---

This is caused by SqlException changes, where I now actually print out the 
cause of an exception in JDK 1.3, whereas before it was just swallowed up into 
the dark space of the runtime.  I'll run derbyall with JDK 1.3 and fix the 
masters.

 big decimal error diff in derbyall lang/procedure test run in the 
 DerbyNetClient - jdk1.3 specific
 --

  Key: DERBY-904
  URL: http://issues.apache.org/jira/browse/DERBY-904
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.2.0.0
  Environment: sun jdk1.3.1
 Reporter: Mike Matrigali
 Priority: Critical


 derby all regression test failure in the following test.  Most recently it 
 failed in the 1/27 derby build.  It also failed on 1/20.  It ran fine on 
 1/13.  Have
 not had time to narrow down further.  Did note that there is a separate 
 master for this test , but no jdk131 specific masters that I could see.
 *** Start: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:30:23 ***
 274 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 10243.. See 
 attached Throwable.
 274a274
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 10243.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 10243.
 337 del
  EXPECTED SQL Exception: Invalid argument: parameter index 2 is not an OUT 
 or INOUT parameter.
 337a337
  EXPECTED SQL Exception: XN009.S : [0] 2
 355 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 102.33.. See 
 attached Throwable.
 355a355
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 102.33.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 102.33.
 Test Failed.
 *** End:   procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:31:39 ***

-- 
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

[jira] Assigned: (DERBY-904) big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific

 [ http://issues.apache.org/jira/browse/DERBY-904?page=all ]

David Van Couvering reassigned DERBY-904:
-

Assign To: David Van Couvering

 big decimal error diff in derbyall lang/procedure test run in the 
 DerbyNetClient - jdk1.3 specific
 --

  Key: DERBY-904
  URL: http://issues.apache.org/jira/browse/DERBY-904
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.2.0.0
  Environment: sun jdk1.3.1
 Reporter: Mike Matrigali
 Assignee: David Van Couvering
 Priority: Critical


 derby all regression test failure in the following test.  Most recently it 
 failed in the 1/27 derby build.  It also failed on 1/20.  It ran fine on 
 1/13.  Have
 not had time to narrow down further.  Did note that there is a separate 
 master for this test , but no jdk131 specific masters that I could see.
 *** Start: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:30:23 ***
 274 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 10243.. See 
 attached Throwable.
 274a274
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 10243.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 10243.
 337 del
  EXPECTED SQL Exception: Invalid argument: parameter index 2 is not an OUT 
 or INOUT parameter.
 337a337
  EXPECTED SQL Exception: XN009.S : [0] 2
 355 del
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
 Overflow occurred during numeric data type conversion of 102.33.. See 
 attached Throwable.
 355a355
  EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
  Overflow occurred during numeric data type conversion of 102.33.. See 
  attached Throwable. Caused by exception class 
  org.apache.derby.client.am.ConversionException: [converters] Overflow 
  occurred during numeric data type conversion of 102.33.
 Test Failed.
 *** End:   procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
 2006-01-22 05:31:39 ***

-- 
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

[jira] Assigned: (DERBY-905) derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 specific

 [ http://issues.apache.org/jira/browse/DERBY-905?page=all ]

David Van Couvering reassigned DERBY-905:
-

Assign To: David Van Couvering

 derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 
 specific
 --

  Key: DERBY-905
  URL: http://issues.apache.org/jira/browse/DERBY-905
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.1.2.2
  Environment: sun jdk1.3.1_15
 Reporter: Mike Matrigali
 Assignee: David Van Couvering
  Fix For: 10.2.0.0


 The following nightly regression happened in the 1/27 codeline, it also 
 failed on 1/20 but worked on 1/13.
 *** Start: LOBTest jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 2006-01-29 
 05:59:59 ***
 48 del
  1 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Date.)
 48a48
  1 getDate  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 101is invalid for requested 
  conversion to java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null)
 56 del
  1 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Time.)
 57 del
  1 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Timestamp.)
 57a56,57
  1 getTime  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 101is invalid for requested 
  conversion to java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null)
  1 getTimeStamp -   EXCEPTION (Invalid data 
  conversion: Parameter instance 101is invalid for requested 
  conversion to java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f)
 71 del
  2 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Date.)
 71a71
  2 getDate  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 102 is invalid for requested conversion to 
  java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null)
 79 del
  2 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Time.)
 80 del
  2 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 102 is invalid for requested conversion to 
 java.sql.Timestamp.)
 80a79,80
  2 getTime  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 102 is invalid for requested conversion to 
  java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null)
  2 getTimeStamp -   EXCEPTION (Invalid data 
  conversion: Parameter instance 102 is invalid for requested conversion to 
  java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f)
 94 del
  3 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Date.)
 94a94
  3 getDate  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 103 is invalid for requested conversion to 
  java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null)
 102 del
  3 getTime  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Time.)
 103 del
  3 getTimeStamp -   EXCEPTION (Invalid data 
 conversion: Parameter instance 103 is invalid for requested conversion to 
 java.sql.Timestamp.)
 103a102,103
  3 getTime  -   EXCEPTION (Invalid data 
  conversion: Parameter instance 103 is invalid for requested conversion to 
  java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null)
  3 getTimeStamp -   EXCEPTION (Invalid data 
  conversion: Parameter instance 103 is invalid for requested conversion to 
  java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f)
 610 del
  1 getDate  -   EXCEPTION (Invalid data 
 conversion: Parameter instance 101is invalid for requested conversion 
 to java.sql.Date.)

[jira] Assigned: (DERBY-906) parameterMapping test in DerbyAll nightly regression under DerbyNetClient, specific to jdk1.3.1

 [ http://issues.apache.org/jira/browse/DERBY-906?page=all ]

David Van Couvering reassigned DERBY-906:
-

Assign To: David Van Couvering

 parameterMapping test in DerbyAll nightly regression under DerbyNetClient, 
 specific to jdk1.3.1
 ---

  Key: DERBY-906
  URL: http://issues.apache.org/jira/browse/DERBY-906
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.1.2.2
  Environment: sun jdk1.3.1_15
 Reporter: Mike Matrigali
 Assignee: David Van Couvering
 Priority: Critical
  Fix For: 10.2.0.0


 The following regression test  failed on 1/27 and 1/20, but did not fail on 
 1/13.
 It looks to be specific to jdk1.3.1_15 - have not seen errors in 1.4 or 1.5 
 runs.
 *** Start: parameterMapping jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 
 2006-01-29 06:01:00 ***
 1257 del
getDate= (?):Invalid data conversion: Parameter instance 32   
 is invalid for requested 
 conversion to java.sql.Date. JDBC FAIL CHAR(60)
 1258 del
getTime= (?):Invalid data conversion: Parameter instance 32   
 is invalid for requested 
 conversion to java.sql.Time. JDBC FAIL CHAR(60)
 1259 del
getTimestamp= (?):Invalid data conversion: Parameter instance 32  
  is invalid for requested 
 conversion to java.sql.Timestamp. JDBC FAIL CHAR(60)
 1259a1257,1259
getDate= (?):Invalid data conversion: Parameter instance 32   
  is invalid for requested 
  conversion to java.sql.Date. Caused by exception class 
  java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
getTime= (?):Invalid data conversion: Parameter instance 32   
  is invalid for requested 
  conversion to java.sql.Time. Caused by exception class 
  java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
getTimestamp= (?):Invalid data conversion: Parameter instance 32  
   is invalid for 
  requested conversion to java.sql.Timestamp. Caused by exception class 
  java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
  hh:mm:ss.f JDBC FAIL CHAR(60)
 1429 del
getDate= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Date. JDBC FAIL VARCHAR(60)
 1430 del
getTime= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Time. JDBC FAIL VARCHAR(60)
 1431 del
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Timestamp. JDBC FAIL VARCHAR(60)
 1431a1429,1431
getDate= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Date. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
getTime= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Time. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Timestamp. Caused by exception 
  class java.lang.IllegalArgumentException: Timestamp format must be 
  -mm-dd hh:mm:ss.f JDBC FAIL VARCHAR(60)
 1601 del
getDate= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Date. JDBC FAIL LONG VARCHAR
 1602 del
getTime= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Time. JDBC FAIL LONG VARCHAR
 1603 del
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
 invalid for requested conversion to java.sql.Timestamp. JDBC FAIL LONG VARCHAR
 1603a1601,1603
getDate= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Date. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
getTime= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Time. Caused by exception 
  class java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
  invalid for requested conversion to java.sql.Timestamp. Caused by exception 
  class java.lang.IllegalArgumentException: Timestamp format must be 
  -mm-dd hh:mm:ss.f JDBC FAIL LONG VARCHAR
 Test Failed.
 *** End:

Re: Discussion of how to map the recovery time into Xmb of log --Checkpoint issue

2006-01-31 Thread Raymond Raymond


Mike,
 Last time we discussed about how to map the recovery time into Xmb of log.
I have been thinking on it recently and have a proposal.
 How about when the very first time derby boots (not every time) on a 
certain
machine, we let the user to chose whether he (or she) want to do some 
statistic
collection about the system performance. If he (or she) want to do, derby 
runs
some test, if not, derby doesn't run test. Later, just as what you said, we 
let derby
collect information every time it does recovery to refine the former 
information.

  Thanks.


Raymond

_
Dont just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

[jira] Created: (DERBY-907) regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me)

regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me)


 Key: DERBY-907
 URL: http://issues.apache.org/jira/browse/DERBY-907
 Project: Derby
Type: Bug
Versions: 10.2.0.0
Reporter: Mike Matrigali
Priority: Critical


It looks like this test may be using a class that does not exist in j2me, can 
someone with j2me
knowledge take a look?  If so test either should not run there, or test may 
need to change.  This 
failed from 1/27 codeline, last passed 1/13 that I know of.

*** Start: RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 
2006-01-29 20:40:13 ***
1 del
 Count: 2 Sum: 1
2 del
 Inserting records ...
3 del
 Shutting down database ...
4 del
 Database shutdown completed
5 del
 Starting restore with roll-forward recovery..
6 del
 Verifying database ...
7 del
 Count: 256 Sum: 32640
7 add
 Exception in thread main java.lang.NoClassDefFoundError: 
 javax.sql.DataSource
Test Failed.
*** End:   RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 
2006-01-29 20:40:14 ***


-- 
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

[jira] Assigned: (DERBY-907) regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me)

2006-01-31 Thread Deepa Remesh (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-907?page=all ]

Deepa Remesh reassigned DERBY-907:
--

Assign To: Deepa Remesh

 regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me)
 

  Key: DERBY-907
  URL: http://issues.apache.org/jira/browse/DERBY-907
  Project: Derby
 Type: Bug
 Versions: 10.2.0.0
 Reporter: Mike Matrigali
 Assignee: Deepa Remesh
 Priority: Critical


 It looks like this test may be using a class that does not exist in j2me, can 
 someone with j2me
 knowledge take a look?  If so test either should not run there, or test may 
 need to change.  This 
 failed from 1/27 codeline, last passed 1/13 that I know of.
 *** Start: RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 
 2006-01-29 20:40:13 ***
 1 del
  Count: 2 Sum: 1
 2 del
  Inserting records ...
 3 del
  Shutting down database ...
 4 del
  Database shutdown completed
 5 del
  Starting restore with roll-forward recovery..
 6 del
  Verifying database ...
 7 del
  Count: 256 Sum: 32640
 7 add
  Exception in thread main java.lang.NoClassDefFoundError: 
  javax.sql.DataSource
 Test Failed.
 *** End:   RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 
 2006-01-29 20:40:14 ***

-- 
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

[jira] Updated: (DERBY-907) regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me)

 [ http://issues.apache.org/jira/browse/DERBY-907?page=all ]

Mike Matrigali updated DERBY-907:
-

Component: Regression Test Failure

 regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me)
 

  Key: DERBY-907
  URL: http://issues.apache.org/jira/browse/DERBY-907
  Project: Derby
 Type: Bug
   Components: Regression Test Failure
 Versions: 10.2.0.0
 Reporter: Mike Matrigali
 Assignee: Deepa Remesh
 Priority: Critical


 It looks like this test may be using a class that does not exist in j2me, can 
 someone with j2me
 knowledge take a look?  If so test either should not run there, or test may 
 need to change.  This 
 failed from 1/27 codeline, last passed 1/13 that I know of.
 *** Start: RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 
 2006-01-29 20:40:13 ***
 1 del
  Count: 2 Sum: 1
 2 del
  Inserting records ...
 3 del
  Shutting down database ...
 4 del
  Database shutdown completed
 5 del
  Starting restore with roll-forward recovery..
 6 del
  Verifying database ...
 7 del
  Count: 256 Sum: 32640
 7 add
  Exception in thread main java.lang.NoClassDefFoundError: 
  javax.sql.DataSource
 Test Failed.
 *** End:   RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 
 2006-01-29 20:40:14 ***

-- 
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

Re: Negative test case (Re: [jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client)

2006-01-31 Thread Bryan Pendleton

If the reader is in TRANSACTION_READ_UNCOMMITTED isolation mode and 
then another connection updated the LOB,  the reader  should get an 
IOException. on the next read.


Reading your comment above, I wrote test code attached to this mail, and 
tried executing it with my latest patch, which is not submitted yet.

Then I found no Exception happens at all.

Are there any misunderstanding you in my test code ?
Or is this unlucky success ?


I think your test program is good, but apparently it does not provoke
the exception that Kathey has in mind.

It occurs to me that, with your new code, lob data should be fetched
from the server in chunks of approximately 32K, so I think that you
may need to incorporate that information into your test program.

That is, when the first connection goes back to read the second set of
256 bytes of blob data from the input stream, it might just be returning
cached data from the first 32K segment that was returned from the server,
and it might be that it won't encounter the server-side exception until
it exhausts that first 32K segment and returns to the server for more data.

What if you do something like this:

1) Initialize the blob column to contain a lot of data: e.g., 128K bytes
2) Have the first connection fetch the first 256 bytes, as you do now.
3) Have the second transaction update the blob to replace it with a
   very short value: e.g., 500 bytes of data total.
4) Then, have the first transaction attempt to fetch *all* the blob data.

Here are some things that I think *might* happen at step 4:
1) The first transaction might get an end-of-blob after 500 bytes total.
2) The first transaction might get all 256K bytes of the original blob.
3) The first transaction might get 32K bytes of the original blob, then
   get an end-of-blob
4) The first transaction might get 32K bytes of the original blob, then
   get an IO Exception (I think this may be the behavior that Kathey was
   trying to expose).

thanks,

bryan

[jira] Assigned: (DERBY-628) setNull() using Types.VARCHAR for a CLOB parameter fails in embedded mode.

 [ http://issues.apache.org/jira/browse/DERBY-628?page=all ]

Satheesh Bandaram reassigned DERBY-628:
---

Assign To: Satheesh Bandaram

 setNull() using Types.VARCHAR for a CLOB parameter fails in embedded mode.
 --

  Key: DERBY-628
  URL: http://issues.apache.org/jira/browse/DERBY-628
  Project: Derby
 Type: Bug
   Components: JDBC
 Reporter: A B
 Assignee: Satheesh Bandaram
 Priority: Minor
  Fix For: 10.2.0.0
  Attachments: setNull.java

 If I attempt to call PreparedStatement.setNull() and specify Types.VARCHAR 
 when the actual parameter type (as determined at bind time) is CLOB, Derby in 
 embedded mode will throw an error, while Derby in client/server mode will 
 succeed.
 Ex. running the following code:
 st.execute(create table t1 (c clob));
 PreparedStatement pSt = conn.prepareStatement(
 insert into t1 values (?));
 try {
 pSt.setNull(1, Types.VARCHAR);
 pSt.execute();
 System.out.println(Error did NOT reproduce.);
 } catch (SQLException se) {
 System.out.println(Error reproduced:);
 se.printStackTrace();
 }
 Against Derby embedded, the result will be:
   Error reproduced:
   SQL Exception: An attempt was made to get a data value of type 'CLOB' from 
 a data value of type 'VARCHAR'.
 But against the Network Server, everything works fine.  Derby embedded will 
 work in other cases where compatible types are used (ex. using setNull() with 
 Types.INTEGER for a BIGINT parameter), but fails for this particular 
 situation. Thus I'm assuming this is _not_ intentional (i.e. that the above 
 code should work). 
 Looks like the problem is in iapi.types.DataTypeDescriptor:
 private static boolean isCharacterType(int jdbcType) {
 switch (jdbcType) {
 case Types.CHAR:
 case Types.VARCHAR:
 case Types.LONGVARCHAR:
 return true;
 default:
 return false;
 }
 }
 I think CLOB should be included in this list, too, shouldn't it?  In 
 iapi.types.TypeId, isStringTypeId is true for CLOBs as well as for the 
 other character types, so it seems like the above method should have similar 
 logic.

-- 
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

[jira] Created: (DERBY-908) YEAR,SECOND,MONTH, MINUTE, HOUR and DAY functions have incorrect information on durations.

YEAR,SECOND,MONTH, MINUTE, HOUR and DAY functions have incorrect information on 
durations.
--

 Key: DERBY-908
 URL: http://issues.apache.org/jira/browse/DERBY-908
 Project: Derby
Type: Bug
  Components: Documentation  
Versions: 10.1.1.0
Reporter: Daniel John Debrunner
Priority: Minor
 Fix For: 10.2.0.0


All these functions in the reference manual have a sentence like:
(this is from DAY)

If the argument is a time duration or timestamp duration: The result is the day 
part of the value, which is an integer between -99 and 99. A nonzero result has 
the same sign as the argument.

This can be removed since Derby does not support durations. Then the 
surrounding text probably needs re-work as it leaves only a single type of 
argument.

-- 
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

[jira] Commented: (DERBY-896) Cast date to timestamp results in ERROR 42846: Cannot convert types 'DATE' to 'TIMESTAMP'.