date:20060131

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

Satheesh Bandaram commented on DERBY-896:
-

Thanks Bernt for your info about SQL standards. I do think this is a useful 
cast to support in Derby. But current code doesn't ,so we could 1) Leave the 
documentation as is and consider this to be a "bug" in Derby OR 2) Make the 
documentation match product code and mark this bug as Improvement.

Any suggestions?


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

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

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

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] 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.IllegalArg

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

[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

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



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

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

[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

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

[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.IllegalArgumentEx

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

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

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

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

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

Myrna

[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

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

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

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

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

ICLA (CLA) etc

2006-01-31 Thread scott hutinger


Dan pretty much spelled everything out for myself about the ICLA etc...

thanks,
scott

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

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)" 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-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-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 = 0<3;
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-868) language specific docs need implemented

2006-01-31 Thread scott hutinger (JIRA)

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

scott hutinger commented on DERBY-868:
--

BTW,  the confusion I stated about clicking on the ASF agree button is all 
mine.  Not Halley...

So no confusion exists about who is confused about what.  I just find it 
strange that two items need to exist, although if I think about it enough, then 
I can see the need for two items.  One (the ICLA) states the obvious, and the 
button on the web pages states that this is a 'specific' item, not the general 
one.

Sorry for the digression...  Everyone.

> 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-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: 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 a fixed 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 saw the 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 information in my first reply on this thread, I hadn't thought it all through, 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.

The clientside 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 still like to pursue 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 an unreasonable hardship. As you might have noticed, I did take it on to 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. I haven't tested this. But would it be ok? Is there a better approach?
- all tests run with either 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 back for every test, i.e. uninstall security Manager somehow? Would that be a slowing down things?
Myrna

[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

[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-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 = 0<3;
> 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-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-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] 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=0<3;
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=(0<3);
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 = 0<3;
> 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_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-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-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

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-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-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] 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-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 = 0<3;
> 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] 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 = 0<3;
> 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-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

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{

[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 = 0<3

> 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 = 0<3;
> 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-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