Google Git
Sign in
eclipse / cdo / cdo / feb16534f639544ee1e34f41f94d625c93af48ca / . / features / org.eclipse.emf.cdo.server.product-feature / rootfiles / derby / RELEASE-NOTES.html
blob: fc3ee58848e0d2b172a628ee57c25c21b8ad15af [file] [log] [blame]
<html>
<title>Release Notes for Derby 10.3.1.4</title>
<body>
<h1>
<a name="Release Notes for Derby 10.3.1.4"></a>Release Notes for Derby 10.3.1.4</h1>
<blockquote>
<p>These notes describe the difference between Derby release 10.3.1.4 and the preceding release 10.2.2.0.</p>
</blockquote>
<ul>
<li>
<a href="#Overview">Overview</a>
</li>
<li>
<a href="#New Features">New Features</a>
</li>
<li>
<a href="#CHANGES">CHANGES</a>
</li>
<li>
<a href="#Issues">Issues</a>
</li>
<li>
<a href="#Open Bugs">Open Bugs</a>
</li>
<li>
<a href="#Build Environment">Build Environment</a>
</li>
</ul>
<h2>
<a name="Overview"></a>Overview</h2>
<blockquote>
<p>
Derby is a pure Java relational database engine using standard SQL and
JDBC as its APIs.
</p>
<p>
Derby functionality includes:
</p>
<ul>
<li>Embedded engine with JDBC drivers</li>
<li>Network Server</li>
<li>Network client JDBC drivers</li>
<li>Command line tools: ij (SQL scripting), dblook (schema dump) and sysinfo (system info)</li>
</ul>
<p>
Derby 10.3.1.4 runs on the following platforms:
</p>
<ul>
<li><b>JDK 1.4 and Java 5</b> - Here Derby supports the JDBC 3.0 interface.</li>
<li><b>Java 6</b> - Here Derby supports the JDBC 4.0 interface.</li>
<li><b>CDC/Foundation 1.1</b> - Here Derby supports the JSR 169 interface.</li>
</ul>
</blockquote>
<h2>
<a name="New Features"></a>New Features</h2>
<blockquote>
<p>
This is a minor release. The following table lists new features that were added and notable improvements that were made:
</p>
</blockquote>
<ul>
<table border="2">
<tr>
<td><b>Feature</b></td><td><b>Description</b></td><td><b>Issue Id(s)</b></td>
</tr>
<tr>
<td>DBA Powers</td><td>Control who can shutdown, encrypt and upgrade databases.</td><td>Master JIRA: <a href="http://issues.apache.org/jira/browse/DERBY-2264">DERBY-2264</a></td>
</tr>
<tr>
<td> Secure Server </td><td> Make the Network Server secure by default. </td><td> Master JIRA: <a href="https://issues.apache.org/jira/browse/DERBY-2196">DERBY-2196</a> </td>
</tr>
<tr>
<td> Language Based Ordering </td><td> Add built in language based ordering and like processing to Derby. </td><td> Master JIRA: <a href="https://issues.apache.org/jira/browse/DERBY-1478">DERBY-1478</a> </td>
</tr>
<tr>
<td> Alter Table </td><td> You can now DROP or RENAME a column. Together with a number of enhancements in 10.2, this means that most dynamic schema modifications are now possible </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-396">DERBY-396</a> <a href="https://issues.apache.org/jira/browse/DERBY-1489">DERBY-1489</a> <a href="https://issues.apache.org/jira/browse/DERBY-1490">DERBY-1490</a> <a href="https://issues.apache.org/jira/browse/DERBY-1926">DERBY-1926</a> <a href="https://issues.apache.org/jira/browse/DERBY-1909">DERBY-1909</a> <a href="https://issues.apache.org/jira/browse/DERBY-2042">DERBY-2042</a></td>
</tr>
<tr>
<td> SSL/TLS </td><td> Implement SSL/TLS communication between client and server </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-2108">DERBY-2108</a> <a href="https://issues.apache.org/jira/browse/DERBY-2356">DERBY-2356</a> <a href="https://issues.apache.org/jira/browse/DERBY-2272">DERBY-2272</a> <a href="https://issues.apache.org/jira/browse/DERBY-2273">DERBY-2273</a> </td>
</tr>
<tr>
<td> Blob/Clob API </td><td> Support all JDBC API methods for Blob/Clob, both for embedded driver and client driver </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-1341 ">DERBY-1341 </a>, <a href="https://issues.apache.org/jira/browse/DERBY-1285">DERBY-1285 </a>, <a href="https://issues.apache.org/jira/browse/DERBY-1286">DERBY-1286 </a>, <a href="https://issues.apache.org/jira/browse/DERBY-2443">DERBY-2443 </a>, <a href="https://issues.apache.org/jira/browse/DERBY-2444">DERBY-2444 </a>, <a href="https://issues.apache.org/jira/browse/DERBY-2730">DERBY-2730 </a> </td>
</tr>
<tr>
<td> Client Side Tracing </td><td> Provide a way to enable client tracing without changing the application </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-1275">DERBY-1275</a> </td>
</tr>
<tr>
<td> Import/Export of Blob/Clob</td><td> Add support for import/export of tables with clob, blob and other binary type columns</td><td> <a href="https://issues.apache.org/jira/browse/DERBY-378">DERBY-378</a> </td>
</tr>
<tr>
<td> JDBC methods for autogenerated keys </td><td> Implement JDBC methods for autogenerated keys for Embedded </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-2631">DERBY-2631</a> </td>
</tr>
<tr>
<td> CREATE TABLE AS <subquery> WITH NO DATA </td><td> Enable Create of a new empty table based upon a sub query </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-64">DERBY-64</a></td>
</tr>
<tr>
<td> XATransaction timeout </td><td> Support for XAResource.setTransactionTimeout</td><td>Master JIRA: <a href="https://issues.apache.org/jira/browse/DERBY-2432">DERBY-2432</a></td>
</tr>
<tr>
<td>
SYSCS_UTIL.SYSCS_SET_USER_ACCESS</br>
SYSCS_UTIL.SYSCS_GET_USER_ACCESS</br>
</td><td>
Add a system procedure to set a user's connection level authorization.
</td><td>
<a href="http://issues.apache.org/jira/browse/DERBY-2735">DERBY-2735</a>
</td>
</tr>
<tr>
<td>SYSCS_UTIL.SYSCS_EMPTY_STATEMENT_CACHE</td><td>Create a procedure to empty the statement cache exposing the existing functionality.</td><td><a href="http://issues.apache.org/jira/browse/DERBY-2772">DERBY-2772</a></td>
</tr>
<tr>
<td>support for diagnostic vti tables that take parameters</td><td>Implement support for diagnostic vti tables that take parameterss.</td><td><a href="http://issues.apache.org/jira/browse/DERBY-2152">DERBY-2152</a></td>
</tr>
<tr>
<td>FOR EACH/MODE DB2SQL in CREATE TRIGGER optional</td><td>Make FOR EACH clause and MODE DB2SQL phrase in CREATE TRIGGER statement optional.</td><td><a href="http://issues.apache.org/jira/browse/DERBY-1953">DERBY-1953</a></td>
</tr>
<tr>
<td>ANSI TRIM</td><td>Add ANSI TRIM implementation</td><td><a href="http://issues.apache.org/jira/browse/DERBY-1623">DERBY-1623</a></td>
</tr>
<tr>
<td> Performance </td><td> Reduce CPU usage in embedded Derby. Main areas being worked on are: Lock manager and latching, reduced use of synchronized data structures, optimize use of bit sets.</td><td> <a href="https://issues.apache.org/jira/browse/DERBY-1704">DERBY-1704</a> <a href="https://issues.apache.org/jira/browse/DERBY-2107">DERBY-2107</a> <a href="https://issues.apache.org/jira/browse/DERBY-2149">DERBY-2149</a> <a href="https://issues.apache.org/jira/browse/DERBY-2150">DERBY-2150</a> <a href="https://issues.apache.org/jira/browse/DERBY-2191">DERBY-2191</a> <a href="https://issues.apache.org/jira/browse/DERBY-2226">DERBY-2226</a> </td>
</tr>
<tr>
<td> Performance </td><td> Improve Derby's treatment of IN-lists to allow the optimizer to consider using indexes when appropriate. </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-47">DERBY-47</a></td>
</tr>
<tr>
<td> Testing </td><td> Switch testing to be pure JUnit based. </td><td> <a href="https://issues.apache.org/jira/browse/DERBY-1952">DERBY-1952</a> & many others </td>
</tr>
<tr>
<td> Memory Usage </td><td> Avoid having to materialize entire LOBs in network client. The client will use locators when requesting operations to be performed on LOBs stored on the server side. </td><td> Master JIRA: <a href="https://issues.apache.org/jira/browse/DERBY-208">DERBY-208</a> </td>
</tr>
<tr>
<td> Platforms </td><td> Minimum JDK support will change to JDK 1.4.2 for J2SE & CDC/Foundation 1.1 for J2ME. (Removes support for JDK 1.3 and J2ME/CDC/Foundation 1.0) </td><td> <a href="http://issues.apache.org/jira/browse/DERBY-1983">DERBY-1983</a> <a href="https://issues.apache.org/jira/browse/DERBY-1985">DERBY-1985</a> <a href="https://issues.apache.org/jira/browse/DERBY-2121">DERBY-2121</a> </td>
</tr>
</table>
</blockquote>
</ul>
<h2>
<a name="CHANGES"></a>CHANGES</h2>
<blockquote>
<p>The following issues are addressed by Derby release 10.3.1.4. These issues are not addressed in the preceding 10.2.2.0 release. </br>
This list includes bugs and improvements, and sub-tasks if the super-task is not fixed in 10.3.1.4, but not issues with only test or web content changes.</p>
<table border="2">
<tr>
<td><b>Issue Id</b></td><td><b>Description</b></td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2973">DERBY-2973</a></td><td>With collation TERRITORY_BASED, insert into table after changing type of column causes assert failure and loss of connection</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2966">DERBY-2966</a></td><td>loss of connection with TERRITORY_BASED collation.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2963">DERBY-2963</a></td><td>AccessControlException connection from remote client.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2960">DERBY-2960</a></td><td>Group by substr() on collated database causes ERROR XJ001</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2955">DERBY-2955</a></td><td>ERROR 42ZA2 creating table with check constraint with literal comparison</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2941">DERBY-2941</a></td><td>With 10.2, Closing a resultset after retrieving a large > 32665 bytes value with Network Server does not release locks</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2925">DERBY-2925</a></td><td>Prevent export from overwriting existing files</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2882">DERBY-2882</a></td><td>Remove references to JDK 1.2 and 1.3 in the documentation</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2868">DERBY-2868</a></td><td>BUILDING.txt doesn't mention junit.jar in list of jars installed in tools/java</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2858">DERBY-2858</a></td><td>Export exceptions swallow useful information</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2849">DERBY-2849</a></td><td>Add a documentation for derby.jdbc.xaTransactionTimeout system/database property</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2837">DERBY-2837</a></td><td>Update docs on STRONG_PASSWORD_SUBSTITUTE_SECURITY/ENCRYPTED_USER_AND_PASSWORD_SECURITY and JCE support</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2809">DERBY-2809</a></td><td>Expressions with a parameter can be assigned the incorrect type</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2806">DERBY-2806</a></td><td>calling getByteLength on org.apache.derby.impl.jdbc.StoreStreamClob makes BinaryStream, fetched before this call, unusable</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2794">DERBY-2794</a></td><td>Document ansi trim functionality</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2793">DERBY-2793</a></td><td>Ensure LIKE predicate follows correct rules for determing collation</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2789">DERBY-2789</a></td><td>DatabaseMetaData .locatorsUpdateCopy() should return true</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2784">DERBY-2784</a></td><td>With JDBC 4 autoloading DriverManager.getProtocol("jdbc:derby:") throws java.sql.SQLException No suitable driver</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2753">DERBY-2753</a></td><td>org.apache.derby.impl.drda.DDMWriter might swallow unexpected exceptions</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2748">DERBY-2748</a></td><td>TimeSlice and Socket-Timeout bounds checking wrong</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2737">DERBY-2737</a></td><td>Change documentation on permissions needed to include read/write for system property derby.storage.jvmInstanceId </td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2694">DERBY-2694</a></td><td>org.apache.derby.impl.drda.DDMWriter uses wrong algorithm to avoid spliting varchar in the middle of a multibyte char.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2692">DERBY-2692</a></td><td>Client driver doesn't chain exceptions received from the server</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2689">DERBY-2689</a></td><td>Deadlock with GenericPreparedStatement</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2686">DERBY-2686</a></td><td>The skip method for some InputStreams and Readers return invalid values</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2673">DERBY-2673</a></td><td>If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2671">DERBY-2671</a></td><td>Errors/messages early in starting the network server through NetworkServerControl.start() are not reported to the PrintWriter passed into start().</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2654">DERBY-2654</a></td><td>Document newly-supported (in embedded mode) JDBC methods for autogenerated keys.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2652">DERBY-2652</a></td><td>Clob.setCharacterStream differs between embedded and client driver</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2619">DERBY-2619</a></td><td> A Derby source release must include the documentation source files</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2613">DERBY-2613</a></td><td>upgrade test problem when attempting to test 10.0.2.1 - </td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2610">DERBY-2610</a></td><td>Queries in metadata.properties allow tablepattern for JDBC methods that do not allow patterns</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2607">DERBY-2607</a></td><td>DatabaseMetaData is not consistent about throwing SqlException when tablename=null</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2606">DERBY-2606</a></td><td>Derby should print the parameters to failed statements to the derby.log when it logs the error </td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2604">DERBY-2604</a></td><td>Implement Clob support for locators</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2603">DERBY-2603</a></td><td>Minor erratum in page of VARCHAR in Derby Reference manual</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2597">DERBY-2597</a></td><td>Language result sets should not reuse current isolation level across executions</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2594">DERBY-2594</a></td><td>Revoking a privilege from an SQL Object should invalidate statements dependent on that object</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2593">DERBY-2593</a></td><td>Add documentation for the CREATE TABLE as subquery clause</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2591">DERBY-2591</a></td><td>DataDictionaryImpl.getSystemSQLName() may generate duplicates</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2584">DERBY-2584</a></td><td>Creating a database with JPOX SchemaTool sometimes gives ArrayIndexOutOfBoundsException when getIndexInfo() is called</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2581">DERBY-2581</a></td><td>Callers of SanityManager.THROWASSERT should chain the exceptions when possible</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2580">DERBY-2580</a></td><td>SanityManager.THROWASSERT(String,Throwable) ignores message argument</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2579">DERBY-2579</a></td><td>AssertFailure class should use JDK's built-in chaining of exceptions</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2570">DERBY-2570</a></td><td>Create a utility which generates Release Notes</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2566">DERBY-2566</a></td><td>OutOfMemory/Sanity-assert failed when updating database</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2558">DERBY-2558</a></td><td>client trhows ArrayIndexOutOfBounds exception instead of parameter out of range </td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2556">DERBY-2556</a></td><td>Code paths for db restore do not use doPrivileged-calls, causing SecurityException</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2551">DERBY-2551</a></td><td>Global Xid value garbled in syscs_diag.transaction_table.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2549">DERBY-2549</a></td><td>ArrayIndexOutOfBoundsException in SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2538">DERBY-2538</a></td><td>Update documentation to describe the expected behavior when a JDBC 4 app creates a JDBC 3 datasource.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2526">DERBY-2526</a></td><td>Wrong results with queries that use the JOIN ... ON syntax to join with views or other non-base table expressions.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2521">DERBY-2521</a></td><td>Building derby outputs (from ant) various information messages that are marked as warning severity.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2520">DERBY-2520</a></td><td>Document new restrictions of database shutdown, encryption and hard upgrade powers</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2511">DERBY-2511</a></td><td>reference manual's description of JDBC4 features has misleading sections</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2501">DERBY-2501</a></td><td>Batch scripts in bin\ report extraneous errors when DERBY_HOME is invalid</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2500">DERBY-2500</a></td><td>Assertion failure preparing query with AND and OR in where clause</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2493">DERBY-2493</a></td><td>Use unsynchronized collections in BackingStoreHashtable</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2489">DERBY-2489</a></td><td>Document the policy-reloading system procedure.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2488">DERBY-2488</a></td><td>When loaded by jvm1.6 - EmbeddedConnectionPoolDataSource is not returning a JDBC 4 compliant PooledConnection object</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2480">DERBY-2480</a></td><td>DriverManager.getConnection leaks memory when connecting to a non-existent database</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2472">DERBY-2472</a></td><td>Use Throwable.initCause() to improve error reporting</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2462">DERBY-2462</a></td><td>org.apache.derby.impl.store.access.BackingStoreHashTableFromScan does not honor ResultSet holdability</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2459">DERBY-2459</a></td><td>Ordering on a CASE-expression casues a NullPointerException when using a UNION</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2456">DERBY-2456</a></td><td>File stream is left open when an exception occurs while setting up a character stream for data export.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2450">DERBY-2450</a></td><td>Clob.Position returning wrong value when operating on Reader</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2444">DERBY-2444</a></td><td>Implement not implemented methods Blob.getBinaryStream(long pos, long length) and Clob. getCharacterStream(long pos, long length) in the Network Client</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2443">DERBY-2443</a></td><td>Implement ResultSet updateClob/updateBlob methods on the NetworkClient</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2431">DERBY-2431</a></td><td>Documentation for DatabaseMetaData should reflect that getColumnPrivileges and getTablePrivileges are implemented</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2425">DERBY-2425</a></td><td>ResultSetMetaData.getColumnDisplaySize() returns a negative value for BLOB columns for client </td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2406">DERBY-2406</a></td><td>XAResource.end does not set the XA transaction state correctly when the XAException is thrown</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2400">DERBY-2400</a></td><td>Javadoc - clean up Cloudscape references in javadoc</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2391">DERBY-2391</a></td><td>"Derby and standards" section of Developer's Guide needs reorganization</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2390">DERBY-2390</a></td><td>DOCS - Merge Working with Derby and Getting Started Guide</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2387">DERBY-2387</a></td><td>DOCs - Reorder the topics in the Ref Manual into Alphabetical order - functions, procedures</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2386">DERBY-2386</a></td><td>timestampdiff function fails when using SQL_TSI_FRAC_SECOND for datepart parameter, except for very small intervals</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2383">DERBY-2383</a></td><td>ReuseFactory should use the constants in java.lang.Boolean</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2381">DERBY-2381</a></td><td>ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a procedure</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2377">DERBY-2377</a></td><td>Document language based ordering which will be implemented by code related sub-tasks of DERBY-1478.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2376">DERBY-2376</a></td><td>Patch available to make .classpath entries portable - relative to ECLIPSE_HOME</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2372">DERBY-2372</a></td><td>Document the secure-by-default network server</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2371">DERBY-2371</a></td><td>Setting a default value for a VARCHAR column fails when column contains data</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2370">DERBY-2370</a></td><td>EXISTS may return the wrong value for sub-queries involving set operations</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2369">DERBY-2369</a></td><td>NetworkServerControl.shutdown() takes at least 1.5 seconds, could be faster.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2365">DERBY-2365</a></td><td>Brushing up pages for MAX and MIN in Derby Reference Manual</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2364">DERBY-2364</a></td><td>improve documentation to explain logged/unlogged operations</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2361">DERBY-2361</a></td><td>Documentation should give examples for using the different security mechanisms</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2355">DERBY-2355</a></td><td>Wrong URL in Eclipse-Plugin Lab Example Jays.java</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2350">DERBY-2350</a></td><td>Use of XML values in the action statement of a trigger throw exceptions.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2331">DERBY-2331</a></td><td>Disallow code in installed jars from resolving classes in the org.apache.derby.* namespace except for public apis.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2330">DERBY-2330</a></td><td>Disallow user-defined SQL routines to resolve to entry points (methods in classes) in the org.apache.derby.* namespace</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2323">DERBY-2323</a></td><td>Update Graphic in Dev Guide - Embedded deployment application overview</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2301">DERBY-2301</a></td><td>Documentation of different executeBatch error handling between embedded and DerbyNetClient needed</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2296">DERBY-2296</a></td><td>getProperties method deprecated on ClientDataSource</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2281">DERBY-2281</a></td><td>Update the Tuning Guide figure about using the statement cache</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2279">DERBY-2279</a></td><td>JDBC3 driver is loaded instead of JDBC4 when running with jdk1.7 </td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2275">DERBY-2275</a></td><td>XSLT changes for PDF output</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2272">DERBY-2272</a></td><td>SSL Documentation</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2263">DERBY-2263</a></td><td>Update the copyright dita files to mark Derby logo images as non-substantive images (for accessibility)</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2262">DERBY-2262</a></td><td>DatabaseMetaData.getTypeInfo returns incorrect MAXIMUM_SCALE value for DECIMAL and NUMERIC types</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2260">DERBY-2260</a></td><td>DatabaseMetaData.getTypeInfo() returns incorrect precision for VARCHAR FOR BIT DATA</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2259">DERBY-2259</a></td><td>DatabaseMetaData.getTypeInfo() SEARCHABLE column returns incorrect information for types that cannot be searched.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2258">DERBY-2258</a></td><td>DatabaseMetaData.getTypeInfo() does not list supported Derby SQL types correctly.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2256">DERBY-2256</a></td><td>Wrong Results: Use of decimal values in an IN-list with INTEGER left operand can lead to extra rows.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2244">DERBY-2244</a></td><td>DatabaseMetaData.supportsExpressionsInOrderBy() returns false</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2243">DERBY-2243</a></td><td>DatabaseMetaData.supportsANSI92EntryLevelSQL() returns false for embedded, true for client driver</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2237">DERBY-2237</a></td><td>Cleanup copyrights in the DITA source and generated docs</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2230">DERBY-2230</a></td><td>AssertFailure: ByteCode Conditional then/else stack mismatch</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2228">DERBY-2228</a></td><td>Support Derby on J2ME/CDC/Foundation 1.1</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2226">DERBY-2226</a></td><td>Move column bitset computation to IndexToBaseRowNode</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2223">DERBY-2223</a></td><td>Let BasePage.fetchFieldFromSlot use the special single-col FetchDescriptor ctor</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2222">DERBY-2222</a></td><td>'show indexes in SCHEMANAME' does not work with the client driver</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2220">DERBY-2220</a></td><td>Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2218">DERBY-2218</a></td><td>Null Pointer Exception when an untyped NULL subquery ("values null") appears outside of the FROM list in a SELECT query.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2216">DERBY-2216</a></td><td>Allow demo SimpleApp to work in J2ME environment</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2214">DERBY-2214</a></td><td>Fix Getting Started file to reflect classpath change</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2208">DERBY-2208</a></td><td>setNetworkServerCP scripts need not add derby.jar into the CLASSPATH</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2202">DERBY-2202</a></td><td>DROP PROCEDURE depends on SET SCHEMA</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2195">DERBY-2195</a></td><td>Nested triggers not working properly after maximum trigger count exception is thrown</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2193">DERBY-2193</a></td><td>[import] ERROR 38000: StringIndexOutOfBoundsException was thrown while evaluating an expression.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2191">DERBY-2191</a></td><td>Cleanup of FormatableBitSet</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2183">DERBY-2183</a></td><td>Trigger recompilation problem when trigger action has its table not qualified with a schema</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2166">DERBY-2166</a></td><td>Implement proper handling of SocketTimeoutException in DRDAConnThread</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2152">DERBY-2152</a></td><td>Support diagnostic vti tables that take parameters, such as SpaceTable</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2150">DERBY-2150</a></td><td>Reduce use of synchronized collections in GenericLanguageConnectionContext</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2149">DERBY-2149</a></td><td>Replace Vectors and Hashtables with ArrayLists and HashMaps in RAMTransaction</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2147">DERBY-2147</a></td><td>LIKE predicate does not accept a pure column reference as righthand operand (gives ERROR 42824)</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2141">DERBY-2141</a></td><td>BlobClob4BlobTest.testPositionBlob() fails with NullPointerException</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2138">DERBY-2138</a></td><td>Remove DataDictionaryContext and associated code</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2137">DERBY-2137</a></td><td>CALL (PROCEDURE) statement documentation in reference manual has incomplete syntax for arguments</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2124">DERBY-2124</a></td><td>Incorrect method name in error message for Connection.setTransactionIsolation method</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2123">DERBY-2123</a></td><td>Remove workaround for old JIT bug from StoredPage</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2122">DERBY-2122</a></td><td>Optimize ContainerLock.isCompatible()</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2121">DERBY-2121</a></td><td>Remove JDK 1.3 build dependency in network server</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2118">DERBY-2118</a></td><td>Change some boundary checks in ArrayInputStream to ASSERTs to improve performance</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2114">DERBY-2114</a></td><td>Let Clock embed a HashMap rather than inherit from Hashtable</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2112">DERBY-2112</a></td><td>Nullpointer on executeBatchRequestX when preparedStatement has no parameters</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2107">DERBY-2107</a></td><td>Move page latching out of the lock manager</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2103">DERBY-2103</a></td><td>After a Lexical Error due to syntax error , even a simple create table does not work on the same connection.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2099">DERBY-2099</a></td><td>Make BasePage.getPageId() final</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2096">DERBY-2096</a></td><td>Change the Parser.parserStatement() to return the more specific StatementNode instead of QueryTreeNode.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2093">DERBY-2093</a></td><td>Error in initSlotTable() can cause NPE or ASSERT rather than reporting page number in corrupt page message.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2088">DERBY-2088</a></td><td>Update the documentation templates. Add comment about changing the reference ID</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2083">DERBY-2083</a></td><td>Shutting down a database loaded from a jar leaves an open file reference to the jar file containing the database.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2067">DERBY-2067</a></td><td>Assert failure in EmbedConnection.restoreContextStack() when running lang/closed.java</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2060">DERBY-2060</a></td><td>SET CURRENT ISOLATION in ref.man refers java.sql.Connection.setTransactionLevel instead of java.sql.Connection.setTransactionIsolation</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2057">DERBY-2057</a></td><td>SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE documentation or implementation error on its arguments.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2053">DERBY-2053</a></td><td>Dev Guide: Syntax errors in SQL tips -&gt; Tricks of the VALUES clause -&gt; Multiple rows</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2050">DERBY-2050</a></td><td>Manipulating CachedItems could be more efficient</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2046">DERBY-2046</a></td><td>Make class org.apache.derby.iapi.store.raw.PageKey final</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2042">DERBY-2042</a></td><td>Provide documentation for new RENAME COLUMN statement</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2040">DERBY-2040</a></td><td>Setting derby.database.classpath to contain installed jars causes the database to be unbootable when a Securitymanager is installed.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2019">DERBY-2019</a></td><td>IJ's describe command does not handle quotes very well</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2018">DERBY-2018</a></td><td>NullPointerException in CREATE VIEW ... VALUES NULL;</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2001">DERBY-2001</a></td><td>Add DITA templates for the 3 topic types into the trunk</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1995">DERBY-1995</a></td><td>Add base schema scripts for order entry</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1993">DERBY-1993</a></td><td>Check in the demo used by the Java in the Database session at Apachecon 2006</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1983">DERBY-1983</a></td><td>Change build system so that base level is JDK 1.4</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1965">DERBY-1965</a></td><td>NetworkServerControlImpl never closes the socket or streams it opens in setUpSocket.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1964">DERBY-1964</a></td><td>Update the documentation of SYSCS_UTIL.SYSCS_COMPRESS_TABLE for the changes that went in as part of DERBY-737</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1959">DERBY-1959</a></td><td>10.2 'Derby Developer's Guide' error/ambiguity.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1956">DERBY-1956</a></td><td>Remove stale code from the statement classes in the client driver</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1955">DERBY-1955</a></td><td>Unquoted path in .bat files may cause errors (Win)</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1953">DERBY-1953</a></td><td>Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1949">DERBY-1949</a></td><td>locate function documentation should clarify behavior when first parameter is empty string</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1947">DERBY-1947</a></td><td>OutOfMemoryError after repeated calls to boot and shutdown a database</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1942">DERBY-1942</a></td><td>There exists difference between behavior of setNull(Types.TIME) and setTiime(null).</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1935">DERBY-1935</a></td><td>Reference Manual - Derby Limitations</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1934">DERBY-1934</a></td><td>Reference Manual updates - J2EE Compliance: Java Transaction API and javax.sql Extensions</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1930">DERBY-1930</a></td><td>Move JDBC implementation notes into the published javadoc</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1929">DERBY-1929</a></td><td>SYSTABLEPERMS and SYSCOLPERMS documentation needs to be updated</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1928">DERBY-1928</a></td><td>Update table "Support for SQL-92 Features: Basic schema manipulation" for GRANT/REVOKE</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1926">DERBY-1926</a></td><td>Provide documentation for ALTER TABLE DROP COLUMN</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1922">DERBY-1922</a></td><td>readme.html under frameworks does not mention about Derby client and some minor typos in example.html</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1920">DERBY-1920</a></td><td>DOCS - Improve topic titles for vague and duplicate topics</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1919">DERBY-1919</a></td><td>Top level index.html page should link to release notes and other items in top-level of a release.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1918">DERBY-1918</a></td><td>INCREMENT of IDENTITY column described as allowing a value of zero in reference manual</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1917">DERBY-1917</a></td><td>Clob.position fails with Embedded driver and large Clobs</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1890">DERBY-1890</a></td><td>improve XSDFI error message</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1879">DERBY-1879</a></td><td>Save meta data related information for an EmbedResultSet at the plan level instead of the ResultSet level improves performance.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1868">DERBY-1868</a></td><td>Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1861">DERBY-1861</a></td><td>Column ordering ASSERT when combining column references and expressions in same ORDER BY</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1852">DERBY-1852</a></td><td>Wrong results: duplicate rows returned for nested UNIONs when they should be eliminated.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1847">DERBY-1847</a></td><td>SELECT statement asserts with XJ001 when attempted to select a newly added column in SQL authorization mode</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1828">DERBY-1828</a></td><td>Access rule violations should use a SQL state starting with '42' according to the SQL standard.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1822">DERBY-1822</a></td><td>LOCK TABLE example and description in reference manual should get replaced by a 'real' example</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1816">DERBY-1816</a></td><td>Client's ResultSet.getTime() on a SQL TIMESTAMP column loses the sub-second resolution and always has a milli-second value of zero.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1815">DERBY-1815</a></td><td>In admin guide examples to start network server on windows with .bat scripts, $DERYBY_INSTALL Is used , I think it should be %DERBY_INSTALL%</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1805">DERBY-1805</a></td><td>Links to element ids inside a topic are broken in PDFs and HTML Books</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1797">DERBY-1797</a></td><td>Building toursdb would go a little faster if it used autocommit off mode.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1795">DERBY-1795</a></td><td>Graphics not copied over for PDF and HTML-single manuals</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1765">DERBY-1765</a></td><td>Update ALTER TABLE documentation to reflect DERBY-119 (ALTER COLUMN [NOT]NULL)</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1753">DERBY-1753</a></td><td>Doc for SYSCS_INPLACE_COMPRESS_TABLE has incorrect procedure name in the java examples.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1752">DERBY-1752</a></td><td>Fix javadoc to account for changes required by new licence header policy.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1709">DERBY-1709</a></td><td>Deprecate scripts in frameworks directory</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1673">DERBY-1673</a></td><td>Compling with jikes not longer works due to recent changes that added -target -source command line flags to each compile</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1665">DERBY-1665</a></td><td>Incorrect JavaDoc for Qualifier interface</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1662">DERBY-1662</a></td><td>Document derbyrun.jar</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1644">DERBY-1644</a></td><td>NPE when inserting values to a table that has a column declared as generated by default as identity</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1624">DERBY-1624</a></td><td>use of direct column name rather than alias make aggregation fail (Hibernate depends on that)</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1623">DERBY-1623</a></td><td>Add ANSI TRIM implementation</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1620">DERBY-1620</a></td><td>SQL CASE statement returns ERROR 42X89 when including NULL as a return value</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1610">DERBY-1610</a></td><td>Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1590">DERBY-1590</a></td><td>Consolidate the *conrefs.dita files in the documentation source tree to a single file.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1589">DERBY-1589</a></td><td>CREATE TABLE throws NullPointerException in Derby SQL Standard Authorization after DROPs and REVOKES</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1588">DERBY-1588</a></td><td>Link "Getting Started...." and "Apache Derby Server ...." in demo.html needs to be linked to actual documents instead of manuals page</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1570">DERBY-1570</a></td><td>The derby configuration, logging and diagnostic properties such as derby.language.logStatementText are hard to find in the documentation</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1535">DERBY-1535</a></td><td>Trial 2 for DERBY-550, improve use of Engine from NetworkServer and reduce memory usage</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1526">DERBY-1526</a></td><td>build should be able to locate the Java runtime libraries from properties not sourced from ${user.home}, but inside the current subversion checkout.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1520">DERBY-1520</a></td><td>Document new SYSCS_DIAG tables</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1519">DERBY-1519</a></td><td>'setAsciiStream' uses different encodings for embedded and client</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1501">DERBY-1501</a></td><td>PreparedStatement#setNull(int parameterIndex, int sqlType) throws SQL Exception if given sqlType is LONGVARBINARY in embedded mode</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1494">DERBY-1494</a></td><td>PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1490">DERBY-1490</a></td><td>Provide ALTER TABLE RENAME COLUMN functionality</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1489">DERBY-1489</a></td><td>Provide ALTER TABLE DROP COLUMN functionality</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1484">DERBY-1484</a></td><td>Client and embedded behave differently when the table name is null in DatabaseMetaData methods</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1440">DERBY-1440</a></td><td>jdk 1.6 client driver omits SQLStates and chained exceptions in error messages</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1434">DERBY-1434</a></td><td>Client can send incorrect database name to server after having made multiple connections to different databases.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1381">DERBY-1381</a></td><td>Document ij.exceptionTrace property</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1377">DERBY-1377</a></td><td>Update copyright headers to comply with new ASF policy</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1355">DERBY-1355</a></td><td>ClientDriver ResultSetMetaData.isAutoIncrement(column) always returns false</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1285">DERBY-1285</a></td><td>Finish JDBC3 Blob implementation</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1275">DERBY-1275</a></td><td>Provide a way to enable client tracing without changing the application</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1132">DERBY-1132</a></td><td>Truncation Error with Concat</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-1054">DERBY-1054</a></td><td>Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-931">DERBY-931</a></td><td>Until DERBY-911 gets fixed, document the difference in behavior between Nework Client Driver and Embedded Driver for setReadOnly</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-908">DERBY-908</a></td><td>YEAR,SECOND,MONTH, MINUTE, HOUR and DAY functions have incorrect information on durations.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-815">DERBY-815</a></td><td>Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-806">DERBY-806</a></td><td>One each deleted or updated from a heap row a new RowPosition object is created.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-801">DERBY-801</a></td><td>Allow parallel access to data files.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-790">DERBY-790</a></td><td>SQLException used by the networked interface to Derby is not serializable</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-729">DERBY-729</a></td><td>Scalar time and date functions return 0 instead NULL when argument is NULL</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-681">DERBY-681</a></td><td>Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-680">DERBY-680</a></td><td>In ij, executing a prepared statement with numeric/decimal parameter fails with NullPointerException in J2ME/CDC/FP</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-630">DERBY-630</a></td><td>create trigger fails with null pointer exception</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-606">DERBY-606</a></td><td>SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-595">DERBY-595</a></td><td>Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-552">DERBY-552</a></td><td>Fetching resources using getResourceAsStream from a jar stored in a database that is archived in a jar file fails</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-538">DERBY-538</a></td><td>Investigate using the standard java.net.URLClassLoader for database class loading.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-537">DERBY-537</a></td><td>SQLJ.INSTALL_JAR and SQLJ.UPDATE_JAR fail when running with a SecurityManager enabled.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-415">DERBY-415</a></td><td>sysinfo with -cp client option should not print error saying DB2 jar file and driver class are missing</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-396">DERBY-396</a></td><td>Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-391">DERBY-391</a></td><td>Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-378">DERBY-378</a></td><td>support for import/export of tables with clob/blob and the other binary data types will be good addition to derby,</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-264">DERBY-264</a></td><td>This enhancement to allow expressions in ORDER BY clause will require documentation changes.</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-234">DERBY-234</a></td><td>Documentation of DateTime types is incomplete</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-208">DERBY-208</a></td><td>Add support to retrieve lobs for Network Server by locator rather than matierializing the LOB</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-183">DERBY-183</a></td><td>Parameter names required in CREATE FUNCTION</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-147">DERBY-147</a></td><td>ERROR 42X79 not consistant ? - same column name specified twice</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-64">DERBY-64</a></td><td>Create a table with a query</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-47">DERBY-47</a></td><td>Some possible improvements to IN optimization</td>
</tr>
</table>
</blockquote>
<h2>
<a name="Issues"></a>Issues</h2>
<blockquote>
<p>Compared with the previous release (10.2.2.0), Derby release 10.3.1.4 introduces the following new features and incompatibilities. These merit your special attention.</p>
<ul>
<li>
<a href="#Note for DERBY-2925">
<p>Note for DERBY-2925:
Prevent export from overwriting existing files
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2757">
<p>Note for DERBY-2757:
Security enhancements to the Network Server may slow down Derby's runtime performance, and
they may trigger SecurityExceptions when Derby executes user-written
functions and procedures.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2729">
<p>Note for DERBY-2729: Blob and Clob objects are released when the
transaction ends and when the connection is closed.</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2610">
<p>Note for DERBY-2610:
The table name can no longer be a pattern in calls to DatabaseMetaData
methods getBestRowIdentifier, getColumnPrivileges, getIndexInfo,
getVersionColumns, getPrimaryKeys, getImportedKeys, getExportedKeys
and getCrossReference.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2526">
<p>Note for DERBY-2526: Queries which use the JOIN ... ON syntax to join with views or other
non-base table expressions may now return different results.<br>
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2443">
<p>Note for DERBY-2443: Added unimplemented methods introduced in the java.sql.ResultSet
interface.</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2430">
<p>Note for DERBY-2430:
The application
will see an error in the event of calling setObject(int targetType,
Blob source) and setObject(int targetType, Clob source) with a
targetType other than Blob and Clob. This will be in conformance with
the embedded behaviour.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2386">
<p>Note for DERBY-2386:
The return type of the timestampdiff function has been changed from INT to BIGINT.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2370">
<p>Note for DERBY-2370: EXISTS predicates with subqueries that use set operators (UNION,
INTERSECT, EXCEPT) may now behave differently.</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2296">
<p>Note for DERBY-2296:
ClientDataSource now supports the createDatabase and shutdownDatabase properties.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2264">
<p>Note for DERBY-2264:
Henceforth, when authentication is enabled
(<code>derby.connection.requireAuthentication</code> has the
value <code>true</code>) <i>and</i> SQL Authentication is enabled
(<code>derby.database.sqlAuthentication</code> has the
value <code>true</code>) some database level operations are restricted
to the <i>database owner</i>.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2256">
<p>Note for DERBY-2256: Use of decimal values in an IN predicate whose left operand is an
INTEGER may now return different results.<br>
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2196">
<p>Note for DERBY-2196:
The user should customize the security policy which the Network Server
now installs by default.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2108">
<p>Note for DERBY-2108:
SSL/TLS implemented for client/server communication.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-2020">
<p>Note for DERBY-2020:
Writing of the transaction log to disk has been changed to open log files in "rwd" mode instead of "rws" if the JVM supports it.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-1942">
<p>Note for DERBY-1942: The use of the TIME data type is more restricted. </p>
</a>
</li>
<li>
<a href="#Note for DERBY-1852">
<p>Note for DERBY-1852: Queries with nested set operators (UNION, INTERSECT, EXCEPT) in a
FROM list may now return different results.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-1828">
<p>Note for DERBY-1828:
Most authorization failures have new error codes.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-1816">
<p>Note for DERBY-1816: ResultSet.getTime() on an SQL TIMESTAMP value now has millisecond
resolution with the Derby client driver.<br>
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-1610">
<p>Note for DERBY-1610:
In a number of usage cases of setNull(int, int) and set*(int, null, int) methods for PreparedStatement and CallableStatement, Derby's Client implementation has been changed, to correctly behave in the same way as the Embedded implementation.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-1519">
<p>Note for DERBY-1519:
Streams obtained by calling get-/setAsciiStream in the client driver use encoding "ISO-8859-1" instead of "US-ASCII".
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-1484">
<p>Note for DERBY-1484:
The table name can no longer be null in calls to DatabaseMetaData methods getBestRowIdentifier, getColumnPrivileges, getIndexInfo, getVersionColumns, getPrimaryKeys, getImportedKeys and getExportedKeys.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-1341">
<p>Note for DERBY-1341: Added unimplemented methods introduced in the JDBC 3.0 and 4.0
specification. Blob and Clob now support all the methods of JDBC 3.0 and 4.0.</p>
</a>
</li>
<li>
<a href="#Note for DERBY-729">
<p>Note for DERBY-729:
Scalar time and date functions should return NULL when the argument is NULL
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-415">
<p>Note for DERBY-415:
Sysinfo now presents separate command switches to check the classpath for the presence of the Derby client and the DB2 JCC driver.
</p>
</a>
</li>
<li>
<a href="#Note for DERBY-208">
<p>Note for DERBY-208: Network Client: Locator-based implementation of Blob/Clob
operations.
</p>
</a>
</li>
</ul>
<hr>
<h3>
<a name="Note for DERBY-2925"></a>Note for DERBY-2925</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Prevent export from overwriting existing files
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
Due to security concerns, and to avoid accidental file damage, Export processing
will not overwrite existing files. As a result, applications may observe some behavioral changes with respect to Export operations.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
<OL>
<LI>SYSCS_UTIL.SYSCS_EXPORT_TABLE: Exports of all the data from a table to an existing file is no longer possible and the user/application must remove the existing file, otherwise ERROR XIE0S will be returned. </LI>
<LI>SYSCS_UTIL.SYSCS_EXPORT_QUERY: Exports of all the data returned from the SELECT statement to an existing file is no longer possible and the user/application must remove the existing file, otherwise ERROR XIE0S will be returned. </LI>
<LI>SYSCS_UTIL.SYSCS_EXPORT_QUERY_LOBS_TO_EXTFILE: Export of the result of a SELECT statement to a main data output file, and the LOB data into a large object auxiliary file to an existing file is no longer possible and the user/application must remove the existing data file and/or large object auxiliary file, otherwise ERROR XIE0S will be returned if the data file exists or ERROR XIE0T will be returned if the large object auxiliary file exists.</LI>
</OL>
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
Due to security concerns and to avoid accidental file damage, Export processing will no longer overwrite an existing file.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
The application needs to specify a different filename which does not exist or delete the existing file before performing the Export operation.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2757"></a>Note for DERBY-2757</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Security enhancements to the Network Server may slow down Derby's runtime performance, and
they may trigger SecurityExceptions when Derby executes user-written
functions and procedures.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
Startup performance for networked applications may degrade after upgrading to 10.3. In addition,
after upgrade, user-written functions and procedures may raise SecurityExceptions.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
In previous releases, the Network Server booted without
installing a default security
manager. Now, the Network Server
installs a security manager if the user forgets to. Application
startup may slow down as the security manager performs initial access
checks on Derby tables. Once all user tables have been touched,
the application should reach steady state and the drag induced
by the security manager should be negligible.
</p>
<p>
In addition, SecurityExceptions may occur if user-written functions
and procedures perform sensitive operations such as
reading/writing files and getting/setting system properties.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
In a client/server configuration, it is particularly important to
protect against other users' mistakes and hacking. Derby is enhancing
security for this configuration.
Now if you neglect to configure a Java security
manager, the Network Server attempts to install its own security
manager with a default policy.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
SecurityExceptions can be avoided by installing your own security
manager with your own policy file, which grants the appropriate
privileges to your user-written code. Instructions on how to do
this can be found in the Derby Developer's Guide in the section
titled "Running Derby under a security manager" and in the
Derby Server and Administration Guide in the section titled
"Running the Network Server under the security manager".
</p>
<p>
If for some reason this is not practical, or if the startup
performance drag is intolerable, then you can instruct the
server to not install a security manager. You do this by booting
the server with the "-noSecurityManager" command line option as
explained in above-mentioned section of the Derby Server and Administration Guide.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2729"></a>Note for DERBY-2729</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>Blob and Clob objects are released when the
transaction ends and when the connection is closed.</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>Applications now get a SQLException with SQL STATE XJ215 when
accessing Blobs and Clobs after the transaction ends or the
connection is closed.</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
In the previous release, Blobs and Clobs were sometimes usable even
after the transaction ended or the connection was closed. Now Blobs
and Clobs are not usable after these events.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
Now Blobs and Clobs store their data in temporary files.
These temporary files are deleted when the transaction ends.
The Blob.free() and Clob.free() methods also delete these temporary files.
This erases the transient state of these large objects and makes them
unusable.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Applications should be revised to not use Blobs and Clobs after
the transaction ends or the connection is closed.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2610"></a>Note for DERBY-2610</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
The table name can no longer be a pattern in calls to DatabaseMetaData
methods getBestRowIdentifier, getColumnPrivileges, getIndexInfo,
getVersionColumns, getPrimaryKeys, getImportedKeys, getExportedKeys
and getCrossReference.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>In the previous release, the methods returned information on all
tables that matched the pattern in the schema. A table name value of
null was treated as a wildcard. Table names now have to match what is
stored in the database. </p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
Calls to the specified methods now fail if the table name parameter is a pattern (no information is returned).
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The previous behavior violated the JDBC standard. The new behavior is correct.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Users must recode applications to specify the table names. When
information on multiple tables is required, the application first has
to get the table names, e.g. by using the DatabaseMetaData method
getTables(), and then use the returned table names as input to the
method in question. </p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2526"></a>Note for DERBY-2526</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>Queries which use the JOIN ... ON syntax to join with views or other
non-base table expressions may now return different results.<br>
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>Applications which use the explicit JOIN ... ON syntax to perform
joins between three or more FROM expressions, at least one of which is
a view, subquery, or other non-base table expression, may have been
seeing incorrect results prior to this release.<br>
</p>
<p>As an example, take the following:<br>
</p>
<p>
<span style="font-family: monospace;"> create table t1 (c0
int);<br>
create table x (c1 int, c2 int);<br>
create table t2 (c3 int, c4 int);<br>
<br>
insert into t1 values 1;<br>
insert into x values (0, 1);<br>
insert into t2 values (0, 2);</span>
</p>
<p>With these tables, the following query should return one row, but
was returning zero rows in previous releases:<br>
</p>
<p>
<span style="font-family: monospace;"> select t1.* from</span>
<span style="font-family: monospace;">
t1 JOIN (select * from x) vw(c1,c2) ON (t1.c0 = vw.c2)</span>
<span style="font-family: monospace;">
JOIN t2 ON (vw.c1 = t2.c3)<br>
</span>
</p>
<p>This problem has been fixed in Derby 10.3.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
The fix for the bug shown above does not introduce any functional
incompatibilities. However, applications may now see different
results if they happen to use queries that rely on the JOIN ... ON
syntax to
join with views, subqueries, or other non-base table expressions. </p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>Due to an error in column reference mappings, it was possible for
earlier versions of Derby
to confuse ON predicate column references with each other, thereby
leading to incorrect computation of transitive closure. This in
turn could lead to the addition of invalid predicates to the query,
which caused wrong results in certain cases.<br>
</p>
<p>By fixing this bug we ensure that the affected queries will always
return the correct results.<br>
</p>
<h4>Application Changes Required</h4>
<p>
No application changes should be needed.<br>
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2443"></a>Note for DERBY-2443</h3>
<blockquote>
<h4>Summary of Change</h4>
<p>Added unimplemented methods introduced in the java.sql.ResultSet
interface.</p>
<!-- DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>Existing application won't be effected by it as these methods are
new implementations. Applications won't be getting Not Implemented
exception anymore.</p>
<!-- DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>To add implementations for unimplemented Blob and Clob related
methods in the ResultSet interface.</p>
<!-- OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>Applications can now make use of the following new methods</p>
<pre>
void updateBlob(int columnIndex, Blob x) throws SQLException
void updateBlob(String columnName, Blob x) throws SQLException
void updateClob(int columnIndex, Clob x) throws SQLException
void updateClob(String columnName, Clob x) throws SQLException
void updateBlob(int columnIndex, InputStream x, long length) throws SQLException
void updateBlob(String columnName, InputStream x, long length) throws SQLException
void updateClob(int columnIndex, Reader x, long length) throws SQLException
void updateClob(String columnName, Reader x, long length) throws SQLException
</pre>
<p>
Detailed
description of these methods can be found in api docs of Java SE 6:
<a href="http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html">ResultSet</a>.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2430"></a>Note for DERBY-2430</h3>
<blockquote>
<!-- SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<P>Derby's Client implementation will return an error matching the
behavior with Embedded in the event when setObject(int targetType,
Blob source) and setObject(int targetType, Clob source) is called
with a targetType other than Blob and Clob.</P>
<!-- DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
The application
will see an error in the event of calling setObject(int targetType,
Blob source) and setObject(int targetType, Clob source) with a
targetType other than Blob and Clob. This will be in conformance with
the embedded behaviour.
</p>
<!-- DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
Derby's Client
implementation and Embedded implementation should behave the same way
from the point of view of an application whenever possible.
</p>
<!-- OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<P>Applications
relying on the Client behaving in the old way will have to be
adjusted.
</P>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2386"></a>Note for DERBY-2386</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
The return type of the timestampdiff function has been changed from INT to BIGINT.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
In the previous release(s), using the builtin timestampdiff function using the SQL_TSI_FRAC_SECOND for the datepart parameter would return an integer overflow error except with very small intervals, less then a second, because the result would exceed the range of an INT.
For intervals larger than a second, SQL_TSI_SECOND had to be used. Now, the result type has been changed to BIGINT and so one can use intervals &gt; 1 sec with SQL_TSI_FRAC_SECOND.
However as a result of the change SQL functions that take the result of the timestampdiff function as a parameter of datatype INT will no longer be resolved.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
As a result of the change, the result type for the timestampdiff function is now BIGINT. Applications which use the return value as a parameter to an SQL function will find that the SQL function can no longer be resolved.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The previous behavior required the application developer to know ahead of time the range for the timestampdiff. Returning BIGINT enables the function to cope with a larger range.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
SQL functions taking the result of a timestampdiff function as a parameter will have to be modified to take a BIGINT parameter instead of INT.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2370"></a>Note for DERBY-2370</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>EXISTS predicates with subqueries that use set operators (UNION,
INTERSECT, EXCEPT) may now behave differently.</p>
<p>
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
Applications which specify set operations inside of an EXISTS predicate
may have been seeing incorrect results for such queries. For
example, the following query should return a single row with column
"OK":
</p>
<pre>
select * from ( values 'OK' ) as T where exists (values 1 except values 2)
</pre>
<p>Prior to Derby 10.3, though, that query would incorrectly return
zero rows.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
Prior to Derby 10.3 a user could specify "SELECT *" within an EXISTS
predicate's set operation and Derby took the "*" to be a single
column. As a result, some queries would compile and execute
without error even when they should have failed. As an example,
the following query would succeed even if table T2 had more than one
column:
</p>
<pre>
select * from ( values 'OK') as T where exists
(select i from T1 union select * from T2)
</pre>
<p>As of version 10.3 Derby no longer allows this. Changes
to fix the incorrect query results make it so that the above query will
now throw an error (42X58) if T2 has more than one column, because then
the left and right result sets of the union would not have the same
number of result columns.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
Due to the way in which Derby internally handles result columns within
an EXISTS predicate, it was possible for queries having EXISTS
predicates with set operators to return incorrect results. By
internally rewriting the EXISTS subquery when it is a set operator, we
can ensure that Derby now evaluates such predicates correctly.
For more on the details of the rewrite, see DERBY-2370.
</p>
<h4>Application Changes Required</h4>
<p>
</p>
<p>As a result of the new internal rewrite, any "*" that appears within
the EXISTS set operation will now be properly expanded. This
means that applications which specify set operations inside of an
EXISTS predicate
must now ensure that the result sets to which a given set operation
applies have the same number of result columns. See the
"incompatibilities" section above for details. No other
application changes are required.</p>
<p>
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2296"></a>Note for DERBY-2296</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
ClientDataSource now supports the createDatabase and shutdownDatabase properties.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>The functionality is new for ClientDataSources. Previously, applications
could not call these methods. Now these methods work:
</p>
<blockquote>
<ul>
<li>setCreateDatabase (String) </li>
<li>getCreateDatabase() </li>
<li>setShutdownDatabase (String) </li>
<li>getShutdownDatabase() </li>
</ul>
</blockquote>
<p>
These methods should behave similarly to the ones in Embedded, i.e.
only valid value for setCreateDatabase is "create", and for
setShutdownDatabase is "shutdown". In essence, at connection time, if
set to a valid value, the property is passed on to the server side with
the ConnectionAttributes.<br>
Note, that the result for setting contradicting properties for
createDatabase and ShutdownDatabase, whether through
setCreateDatabase("create") and setShutdownDatabase("shutdown") or via
setConnectionAttributes("create=true") or ("shutdown=true") is
undefined.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>No incompatibilities were introduced.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
With version 10.2.1.6 an incompatibility with 10.1.1.0 was introduced -
since revision 393003, the undocumented, non-standard but
previously public method, getProperties for Client DataSources was
removed for security reasons. This left only the
setConnectionAttributes method available for creating or shutting down
a database, and caused hardship for applications that had previously
taken advantage of the getProperties method. For instance, in Geronimo
the getProperties method was
previously used to inquire and set whether a create=true was set for a
database.<br>
Support for the four methods already existing for EmbeddedDataSource
was requested for ClientDataSource to compensate for the disappearance
of getProperties as a public method.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>Application code will need to be adjusted if they want to take
advantage of these new methods for ClientDataSources.<br>
<br>
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2264"></a>Note for DERBY-2264</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Henceforth, when authentication is enabled
(<code>derby.connection.requireAuthentication</code> has the
value <code>true</code>) <i>and</i> SQL Authentication is enabled
(<code>derby.database.sqlAuthentication</code> has the
value <code>true</code>) some database level operations are restricted
to the <i>database owner</i>.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
When connecting to an existing database to
<ul>
<li>shut down the database</li>
<li>encrypt a previously unencrypted database</li>
<li>re-encrypt an encrypted database with a new bootPassword or a
new encryption key</li>
<li>perform a full (as opposed to soft) upgrade of the database from
a previous version</li>
</ul>
an SQLException with SQLState "08004" is thrown. For the English
locale the exception string will be one of:
<ul>
<li>User <i>user</i> cannot shut down database <i>database</i>. Only
the database owner can perform this operation.</li>
<li>User <i>user</i> cannot (re)encrypt
database <i>database</i>. Only the database owner can perform this
operation.</li>
<li>User <i>user</i> cannot hard upgrade
database <i>database</i>. Only the database owner can perform this
operation.</li>
</ul>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
In release 10.2, any authenticated user would be able to:
<ul>
<li>Shut down the database.</li>
<li>Encrypt a previously unencrypted database.</li>
<li>Re-encrypt an encrypted database with a new bootPassword or a
new encryption key.</li>
<li>Perform a full (as opposed to soft) upgrade of the database from
a previous version.</li>
</ul>
In 10.3, if both authentication and sqlAuthentication are enabled, an
application which tries to perform any such operation by connecting as
any user other than the <i>database owner</i>, will see an
SQLException with SQLState "08004" and the operation will not be
performed.
</p>
<p>
The check on full upgrade pertains to upgrades from 10.2.* (and
subsequent) releases of Derby only. When upgrading from 10.0 or 10.1
any valid user can still do the full upgrade. This user then becomes
the database owner. The reason for this difference is that the
database owner concept was first introduced in 10.2. Note that once
you upgrade, the database owner can not be changed.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
These changes were introduced to enhance Derby security by limiting operations
which impact all users of a database - with potentially far-reaching
effects - to the data base owner.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Impacted applications must now be changed to perform these operations
as <i>the database owner</i>, that is, supplying the authorization
identifier (i.e. user name) of the database owner when connecting to
perform these operations.
</p>
<p>
<b>Note:</b> The database owner is identical to the authorization
identifier (i.e. user name) used when the database was created or user
name used when upgrading from 10.0 or 10.1 as the case may be. If the
database was created or upgraded <i>without</i> supplying a user name
(authentication not enabled) the database owner defaults to "APP".
</p>
<p>
The following query can be used to show the database owner:
</p>
<p>
<code>
select authorizationid from sys.sysschemas where schemaname = 'SYS';
</code>
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2256"></a>Note for DERBY-2256</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>Use of decimal values in an IN predicate whose left operand is an
INTEGER may now return different results.<br>
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
Applications which use an IN predicate to see if an integer value is
contained within a list of decimal values may have been seeing
incorrect results prior to this release. In some cases rows may
have been missing from the result; in other cases, additional
(incorrect) rows may have been returned.<br>
</p>
<p>As an example, take the following:<br>
</p>
<p style="font-family: monospace;"> create table t1 (i int);<br>
insert into t1 values 1, 2, 3, 4, 5;<br>
</p>
<p style="font-family: monospace;"> -- Following query was
returning zero rows when it should return 1 row.<br>
select * from t1 where i in (4.23, 4);
<br>
</p>
<p>
<span style="font-family: monospace;"> -- Following query
should return zero rows but was returning 1 row.</span>
<span style="font-family: monospace;"> select * from t1 where i
in (2.8, 4.23);<br>
</span>
</p>
<p>This problem has been fixed in Derby 10.3.<br>
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
The fix for the bug shown above does not introduce any functional
incompatibilities. However, applications may now see different
results if they happen to use queries which rely on an IN predicate to
check for integer values within a list of decimal values. </p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>Derby's behavior in previous releases was incorrect and could lead
to wrong results.<br>
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
No application changes should be needed.<br>
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2196"></a>Note for DERBY-2196</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
The user should customize the security policy which the Network Server
now installs by default.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
When booted from the command line, the Network Server now installs a security manager with a default policy.
This policy does not expose the application to any additional
risks. However, the policy is overbroad and the user should
customize it in order to reduce security threats.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<!--
<h4>Incompatibilities with Previous Release</h4>
<p>
Blah blah blah.
</p>
-->
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
Derby is providing more security support.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Instead of relying on the default policy installed by the Network
Server, the user should further limit the scope of privileged operations.
In particular, the
user should fine-tune the blanket read/write privilege granted
on the entire server file system. The user should narrow this
privilege to just the directories needed for backup/restore,
import/export, and jar file loading.
For instructions on how to refine the policy file, please consult
the Derby Server and Administration Guide section titled
"Customizing the Network Server's security policy".
</p>
<p>
This is also an opportunity for the user to enable user authentication
if the Network Server currently runs without
authentication. Running in a client/server configuration without
authentication exposes the application and the server machine to
many threats. It is strongly discouraged. For instructions on enabling
user authentication, please consult the Derby Developer's Guide
section titled "Working with user authentication".
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2108"></a>Note for DERBY-2108</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
SSL/TLS implemented for client/server communication.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
Several error messages have been changed to reflect failure scenarios
which may involve SSL:
</p>
<p>
<b>SQLExceptions:</b>
</p>
<p>
The message<br>
<code>ERROR 58009: A communications error has been detected</code>
<br>has been extended to give the underlying cause. E.g. if the underlying
cause is an SSL problem, you get
<br>
<code>ERROR 58009: A communications
error has been detected. Unrecognized SSL message, plaintext
connection?</code>
</p>
<p>
The message<br>
<code>ERROR 58009: A network protocol error was encountered and the
connection has been terminated: A PROTOCOL Data Stream Syntax Error
was detected. Reason: 0x3.</code>
<br>has been changed to
<br>
<code>ERROR
58009: A network protocol error was encountered and the connection has
been terminated: A PROTOCOL Data Stream Syntax Error was detected.
Reason: 0x3. Plaintext connection attempt to an SSL enabled
server?</code>
</p>
<p>
<b>Other error messages:</b>
</p>
<p>
If the server socket can't be established when a server is started,
the message
<br>
<code>Could not listen on port NNNN on host XXXX</code>
<br>
has been extended to give the underlying cause, e.g:
<br>
<code>Could not listen on port NNNN on host XXXX:
java.net.BindException: Address already in use</code>
</p>
<p>
If a plaintext server is connected by an SSL enabled client, you will
see messages like this in the server log:
<br>
<code>Execution failed
because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT
arg = 0; Error Em Value = 3. Plaintext connection attempt from an
SSL enabled client?</code>
</p>
<p> If a plaintext administration command is used towards an SSL
server, the message <br>
<code>Invalid reply header from network
server: Invalid string xxxx.</code>
<br> has been changed to
<br>
<code>Invalid reply header from network server: Invalid string
xxxx. Plaintext connection attempt to an SSL enabled server?</code>
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
Applications which rely on the content of error message texts may fail.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The messages had to be extended due to more failure scenarios when
connecting a client to a Derby server.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Users must recode applications to recognize the changed messages.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-2020"></a>Note for DERBY-2020</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Writing of the transaction log to disk has been changed to open log files in "rwd" mode instead of "rws" if the JVM supports it.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
With JVMs/OSs that support the functionality, such as JDK version 1.4.2 and up on Solaris, a performance improvement may be noticed. On other platforms, no change may be noticeable.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
For writing the transaction log to disk Derby uses a RandomAccessFile. Before this change, if it was supported by the JVM, the log files were opened in "rws" mode making the file system take care of syncing writes to disk. "rws" mode ensured that both the data and the file meta-data was updated for every write to the file. On some operating systems (e.g. Solaris) this lead to two write operations to the disk for every write issued by Derby. This was limiting the throughput of update intensive applications. By changing the file mode to "rwd" the number of updates to the disk is reduced.
Some JVMs have a bug in the support for "rws" and "rwd" mode. Derby will check for this bug, and if it is detected, Derby will revert back to using "rw" mode and print an appropriate message indicating this in derby.log.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
No changes are needed or possible to benefit from this change. If your JVM supports it, it will be used. If Derby detects that your JVM has a bug in the support for "rwd", a message will be printed to derby.log:<br>
------------ BEGIN ERROR MESSAGE ------------- <br>
LogToFile.checkJvmSyncError: Your JVM seems to have a problem with implicit syncing of log files. Will use explicit syncing instead. <br>
------------ END ERROR MESSAGE ------------- <br>
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1942"></a>Note for DERBY-1942</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>The use of the TIME data type is more restricted. </p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>Applications might encounter an error that indicates incompatible data types, when values are
passed using the TIME data type. </p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>In previous releases, applications could call the setTime method for variables
that use the TIMESTAMP data type, if the passing value was null. Starting with
this release, calling the setTime method fails for variables that use the TIMESTAMP data type,
regardless of the value that is passed.
</p>
<p>Moreover, applications were allowed to pass values that used the TIME data type to
a parameter of the DATETIMEDIFF function in the previous release. Starting with this release,
instead of using the TIME data type, the TIMESTAMP data type must be used to pass a parameter
of the DATETIMEDIFF function. </p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>The TIME data type is classified as a data type for time
information. Unlike the TIMESTAMP and DATE data types, the TIME
data type is special case. The TIME data type does not represent
a specific instant or one time frame but represents all
instants, every day. For example, if TIME is 20:42, this
represents 20:42 regardless of the date. 20:42 today, 20:42
tomorrow, and so forth. Starting with this release, the TIME
data type is regarded completely different from the TIMESTAMP
data type. </p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>Applications using the TIME data type must use the TIMESTAMP data
type instead, if date information is needed besides time
information.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1852"></a>Note for DERBY-1852</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>Queries with nested set operators (UNION, INTERSECT, EXCEPT) in a
FROM list may now return different results.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
The Derby documentation indicates that if the 'ALL' keyword is not
specified when using a set operator, the default behavior is to remove
duplicate rows from the result. There is, however, a specific
type of query in which previous versions of Derby would incorrectly
include duplicate rows, even if "ALL" was not specified. The
queries in question have all of the following characteristics:<br>
</p>
<ol>
<li>A chain of two or more set operators appears in the FROM list of
a SELECT query; <span style="font-style: italic;">and</span>
<br>
</li>
<li> There exists at least one nested set operator in the chain which:<br>
a) is *not* the top-level set operator in the chain, and<br>
b) which does *not* include "ALL"; <span style="font-style: italic;">and</span>
</li>
<li>The result of the set operator from #2 includes duplicate rows; <span style="font-style: italic;">and</span>
</li>
<li>None of the set operators which sit above the set operator from
#2 in the query tree removes duplicates.<br>
</li>
</ol>
<p>A query which satisfies all of these conditions would return
incorrect results (duplicate rows) in previous releases. Consider
the following simple example:<br>
</p>
<span style="font-family: monospace;"> create view vw(i) as
values 1, 2 union values 2 union all values 3;<br>
<br>
-- Both of the following queries are equally affected by this
issue.<br>
<br>
select * from vw;<br>
select * from (values 1, 2
union values 2 union all values 3) x</span>
<br>
<p>In this example the chain of unions is as follows:</p>
<p style="font-family: monospace;">
<pre>
union_1 all
/ \
union_2 values 3
/ \
values 1, 2 values 2
</pre>
</p>
<p>Note that <span style="font-family: monospace;">union_2</span> is
nested within <span style="font-family: monospace;">union_1</span>,
and that <span style="font-family: monospace;">union_2</span> has
duplicate values ("2"). Also note that <span style="font-family: monospace;">union_1</span> has an "ALL" specified
and thus does not remove duplicates. So we've satisfied the above
criteria and we would expect that, since <span style="font-family: monospace;">union_2</span> does not have the "ALL"
keyword, the duplicate "2" rows should be removed before evaluation of <span style="font-family: monospace;">union_1</span>. But in previous
releases of Derby this removal of duplicates did not happen. Thus
the query would incorrectly return four rows, with the value "2" being
duplicated.<br>
</p>
<h4>Incompatibilities with Previous Release</h4>
The fix for the bug shown above does not introduce any functional
incompatibilities. However, applications may see different
results if they happen to use queries which satisfy the conditions
outlined above. Such applications may also see slightly increased
execution times for the relevant queries due to the fact that Derby
internally sorts the nested results to remove duplicates.<br>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The previous behavior gave incorrect results.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
No application changes should be needed.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1828"></a>Note for DERBY-1828</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Most authorization failures have new error codes.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
In the previous release, authorization failures had error codes 2850x
and 04501. In this release, most of these errors have new error codes.
The code changes are: 04501, 2850H, 2850I and 2850J are now 08004.
28506-2850G are now 42500-4250A, 28501 is now 4250B, 28503-28505 are
now 4250C-4250E. Only the error codes have been changed; error
messages are not affected.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
Applications that are dependant on authorization error codes may fail.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The old error codes violated the SQL standard. The new error codes
are correct.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Applications that are dependant on authorization error codes must be
recoded to expect the new codes.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1816"></a>Note for DERBY-1816</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>ResultSet.getTime() on an SQL TIMESTAMP value now has millisecond
resolution with the Derby client driver.<br>
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
JDBC applications which a) use the Derby client driver, and b) use
ResultSet.getTime() to retrieve a java.sql.Time object from an SQL
TIMESTAMP value would, in previous releases, always get a java.sql.Time
object whose milliseconds field was zero. This would be the case
even though a Derby SQL TIMESTAMP has nanosecond resolution.<br>
</p>
<p>With this release the Derby client driver now matches the embedded
driver in that a call to ResultSet.getTime() on an SQL TIMESTAMP will
return a java.sql.Time object with the correct millisecond resolution.<br>
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
This change does not introduce any functional
incompatibilities. Applications using the Derby client driver
will now see correct millisecond values when they call
ResultSet.getTime() to retrieve an SQL TIMESTAMP. </p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>While it is true that a Derby SQL TIME value has by definition
resolution of only a second, the java.sql.Time class is not a direct
mapping to the SQL Type. Rather, it's a JDBC type, and the JDBC
java.sql.Time class has a precision of milliseconds. So when
retrieving a java.sql.Time value from an SQL TIMESTAMP, Derby should
retain the millisecond precision.<br>
</p>
<p>Note that the Derby embedded driver correctly retained millisecond
precision in previous releases. With the latest release, the
client driver now matches that behavior.<br>
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
No application changes should be needed.<br>
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1610"></a>Note for DERBY-1610</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
In a number of usage cases of setNull(int, int) and set*(int, null, int) methods for PreparedStatement and CallableStatement, Derby's Client implementation has been changed, to correctly behave in the same way as the Embedded implementation.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
In a number of method calls involving null values for PreparedStatement and CallableStatement, Derby's Client implementation behaved differently from the Embedded implementation.
Now, in most cases, the Client returns an error where Embedded returns an error and succeeds where Embedded succeeds.
For instance:
<ol>
<li>setNull(LONGVARCHAR) on parameter of type CHAR FOR BIT DATA (Types.BINARY).
In previous releases, Embedded returned an error (SQLState 22005), but the Client did not. Now, both Embedded and Client will return an error.</li>
<li> setNull(LONGVARBINARY) on parameter of type CHAR FOR BIT DATA (Types.BINARY).
In previous releases, this call succeeded with Embedded, but the Client returned an error (SQLState 22005). Now, such a call will succeed with both Embedded and Client.</li>
<li> setNull(LONGVARBINARY) on parameter of type VARCHAR FOR BIT DATA (Types.VARBINARY).
In previous releases, the call succeeded with Embedded, Client returned an error (SQLState 22005). Now, such a call will succeed with both Embedded and Client.</li>
<li> setNull(BINARY) on parameter of type LONG VARCHAR FOR BIT DATA (Types.LONGVARBINARY).
In previous releases, such a call succeeded with Embedded, but Client returned an error (SQLState 22005). Now, such a call will succeed with both Embedded and Client.</li>
<li> setNull(TIME) on parameter of TIMESTAMP.
In previous releases, Embedded returned an error (SQLState 22005), but the Client did not. Now, both Embedded and client will return an error.</li>
</ol>
Similar differences existed with the set&lt;type&gt;(int, null) calls.<br>
Note, that where an error is returned, the actual SQLState returned may still be different between the two implementations.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
Now, in the cases indicated above, the Client and Embedded implementation show the behavior previously shown only with Embedded.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
Derby's Client implementation and Embedded implementation should behave the same way from the point of view of an application whenever possible.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Applications relying on the Client behaving in the old way will have to be adjusted.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1519"></a>Note for DERBY-1519</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Streams obtained by calling get-/setAsciiStream in the client driver use encoding "ISO-8859-1" instead of "US-ASCII".
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
Strange symbols might appear in text, or text seems garbled. Where a
question mark was printed previously, another character (printable or
non-printable) may occur. The described symptoms only apply for the client driver.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
Ascii streams in the client driver can now return 8-bit values in the range 0 -
255, whereas they previously returned 7-bit values in the range 0-127. As a
consequence, all 8-bit values are also accepted as input.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The JDBC specification defines Ascii as values in the range 0 - 255.
"US-ASCII" only contains 7-bit values, and cannot represent
the full range. "ISO-8859-1" can represent the full range.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Applications accessing Ascii streams from Derby through the client driver must
be extended to handle 8-bit values.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1484"></a>Note for DERBY-1484</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
The table name can no longer be null in calls to DatabaseMetaData methods getBestRowIdentifier, getColumnPrivileges, getIndexInfo, getVersionColumns, getPrimaryKeys, getImportedKeys and getExportedKeys.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
In the previous release, a table name value of null was treated as a wildcard. Derby now raises an SQLException if the table name is null.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
Calls to the specified methods now fail if the table name parameter is null (SQLException is thrown).
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The previous behavior violated the JDBC standard. The new behavior is correct.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Users must recode applications to specify the table names. When information on multiple tables is required, the application first has to get the table names, e.g. by using the DatabaseMetaData method getTables(), and then use the returned table names as input to the method in question.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-1341"></a>Note for DERBY-1341</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>Added unimplemented methods introduced in the JDBC 3.0 and 4.0
specification. Blob and Clob now support all the methods of JDBC 3.0 and 4.0.</p>
<!-- DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>Existing application won't be effected by it as these methods are
new implementations. Applications won't be getting Not Implemented
exception anymore.</p>
<!-- DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>To support all the methods in Blob and Clob introduced in the latest JDBC Specification.<br>
<br>
</p>
<!-- OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Applications can now make use of following newly added methods</p>
<span style="font-weight: bold;">java.sql.Blob
</span>
<br>
<div style="margin-left: 40px;">InputStream
getBinaryStream(long pos, long length) throws SQLException <br>
OutputStream
setBinaryStream(long pos)
throws SQLException<br>
int
setBytes(long pos, byte[] bytes)
throws SQLException<br>
int
setBytes(long pos, byte[] bytes, int offset, int len)
throws SQLException<br>
void
truncate(long len)
throws SQLException<br>
</div>
<span style="font-weight: bold;">java.sql.Clob
</span>
<br>
<div style="margin-left: 40px;">Reader
getCharacterStream(long pos, long length)
throws SQLException<br>
OutputStream
setAsciiStream(long pos)
throws SQLException<br>
Writer
setCharacterStream(long pos)
throws SQLException<br>
int
setString(long pos, String str)
throws SQLException<br>
int
setString(long pos, String str, int offset, int len)
throws SQLException<br>
void
truncate(long len)throws SQLException<br>
<br>
</div>
Detailed description of these methods can be found in api docs of Java SE 6<br>
<div style="margin-left: 40px;">
<br>
<a href="http://java.sun.com/javase/6/docs/api/java/sql/Blob.html">http://java.sun.com/javase/6/docs/api/java/sql/Blob.html</a>
<br>
<a href="http://java.sun.com/javase/6/docs/api/java/sql/Clob.html">http://java.sun.com/javase/6/docs/api/java/sql/Clob.html</a>
</div>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-729"></a>Note for DERBY-729</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Scalar time and date functions should return NULL when the argument is NULL
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
In previous releases, the scalar time and date functions returned 0 when the argument is NULL.
This has now been corrected.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
With this release, the scalar time and date functions will return NULL when the argument is NULL.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The previous behavior was incorrect.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Applications that rely on the old behavior will have to be changed to expect/check for NULL as return value instead of 0.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-415"></a>Note for DERBY-415</h3>
<blockquote>
<!--
SUMMARIZE THE ISSUE. This is a one line summary of the issue.
For instance:
Applications may no longer open two InputStreams on the same ResultSet column.
-->
<h4>Summary of Change</h4>
<p>
Sysinfo now presents separate command switches to check the classpath for the presence of the Derby client and the DB2 JCC driver.
</p>
<!--
DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->
<h4>Symptoms Seen by Applications Affected by Change</h4>
<p>
Previously, if you ran "java org.apache.derby.tools.sysinfo -cp client SimpleApp.class" you got a message indicating that the DB2 JCC driver was not found in your classpath, even though you had the Derby Client library in your classpath.
Now "-cp client" only checks for the presence of the Derby client.
To check for the presence of the DB2 JCC driver jar, you can pass the new "-cp db2driver" argument.
</p>
<!--
OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->
<h4>Incompatibilities with Previous Release</h4>
<p>
To check for the presence of the DB2 JCC driver, you must use the new
"-cp db2driver" argument.
</p>
<!--
DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->
<h4>Rationale for Change</h4>
<p>
The behavior has changed in order to eliminate a confusing diagnostic
message.
</p>
<!--
OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->
<h4>Application Changes Required</h4>
<p>
Users who want to check for the presence of the DB2 JCC driver will
need to use the new command switch.
</p>
</blockquote>
<hr>
<h3>
<a name="Note for DERBY-208"></a>Note for DERBY-208</h3>
<blockquote>
<h4>Summary of Change</h4>
<p>Network Client: Locator-based implementation of Blob/Clob
operations.
</p>
<h4>
<!-- DESCRIBE WHAT IT IS THAT THE USER ACTUALLY SEES WHEN THE PROBLEM OCCURS.
For instance:
In the previous release, applications were able to open two
InputStreams on the same column. Depending on how these streams
interacted, the value siphoned out of the column was erratic. Now
Derby raises a SQLException when the application attempts to create
the second InputStream.
-->Symptoms
Seen by Applications Affected by Change</h4>
<p>
<FONT FACE="Thorndale, serif">Memory requirements for handling
large Blob/Clob values in the Network Client are significantly
reduced. As a result of this, applications may observe some
behavioral changes with respect to Blob/Clob operations.</FONT>
</p>
<h4>
<!-- OPTIONAL: DESCRIBE INCOMPATIBILITIES WITH PREVIOUS RELEASE, IF ANY.
For instance:
Applications which open two InputStreams on the ResultSet column now
fail.
-->Incompatibilities
with Previous Release</h4>
<OL>
<LI>Life span for Blob/Clob objects: Blob/Clob objects are no
longer valid after the transaction in which they were created has
been terminated (committed or rolled back).</LI>
<LI>Stream access to Blob/Clob values: Streams obtained to read
from Blob/Clob objects (E.g., Blob.getBinaryStream()), would in
previous releases not reflect any changes made to the object after
the stream was created. In Derby 10.3, it is unpredictable what a
read operation on a stream will see of changes made between the
creation of the stream and the time of the read operation. This
means that applications that interleaves reads and writes of a
Blob/Clob object may observe a changed behavior.</LI>
</OL>
<h4>
<!-- DESCRIBE WHY THE CHANGE WAS MADE.
For instance:
The previous behavior violated the JDBC standard. The new behavior
is correct.
-->Rationale
for Change</h4>
<p>
<FONT FACE="Thorndale, serif">In earlier versions of the Derby
Network Client, Blob and Clob operation caused the entire objects to
be materialized in memory. For large values, this required large
amounts of memory on the client side. To reduce the resource usage,
a locator-based scheme has been implemented. The JDBC driver will
hold references to server-side Blob/Clob values, and use these
references to request the server to perform operations on the values.
Hence, the Network Client will no longer need large amounts of
memory too materialize large values in memory.</FONT>
</p>
<p>
<FONT FACE="Thorndale, serif">The incompatibilities are introduced
because it was difficult to maintain the previous behavior when the
Blob/Clob objects are no longer materialized in memory.</FONT>
</p>
<h4>
<!-- OPTIONAL: DESCRIBE HOW TO REVERT TO THE PREVIOUS BEHAVIOR OR
OTHERWISE AVOID THE INCOMPATIBILITIES INTRODUCED BY THIS CHANGE.
For instance:
Users must recode applications which open multiple streams on the same column.
-->Application
Changes Required</h4>
<p>Applications that access Blob/Clob objects after the transaction
they were created in has committed need to be changed. Make sure
that the commit of the transaction is delayed until the objects are
no longer needed. This means that if the same object is to be used
in several statements, these statements will have to run in the same
transaction (i.e., auto-commit may not be used in such cases). Also
note that if auto-commit is used, a transaction will be committed
when the result set is closed. Hence, when using auto-commit one
must delay the closing of the result set until the Blob/Clob objects
are no longer needed.</p>
</blockquote>
<h2>
<a name="Open Bugs"></a>Open Bugs</h2>
<blockquote>
<p>For open bugs please refer to the JIRA bug tracking system: <a href="http://issues.apache.org/jira/browse/DERBY">http://issues.apache.org/jira/browse/DERBY</a>
</p>
<p>However, of special interest in particular for existing applications are the following bugs open at the time of the 10.3.1.4 release:</p>
<table border="2">
<tr>
<td><b>Issue Id</b></td><td><b>Description</b></td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2436">DERBY-2436</a></td><td>SYSCS_IMPORT_TABLE can be used to read derby files</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2437">DERBY-2437</a></td><td>SYSCS_EXPORT_TABLE can be used to overwrite derby files</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2892">DERBY-2892</a></td><td>Closing a resultset after retrieving a large > 32665 bytes value with Network Server does not release locks</td>
</tr>
<tr>
<td><a href="http://issues.apache.org/jira/browse/DERBY-2905">DERBY-2905</a></td><td>Shutting down embedded Derby does not remove all code, the AutoloadDriver is left registered in the DriverManager.</td>
</tr>
</table>
</blockquote>
<h2>
<a name="Build Environment"></a>Build Environment</h2>
<blockquote>
<p>Derby release 10.3.1.4 was built using the following environment:</p>
<ul>
<li>
<b>Branch</b> - Source code came from the 10.3 branch.</li>
<li>
<b>Machine</b> - SunOS 5.11 snv_48.</li>
<li>
<b>Ant</b> - Apache Ant version 1.6.5 compiled on June 2 2005.</li>
<li>
<b>JDK 1.4</b> - Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03).</li>
<li>
<b>Java 6</b> - Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-b105).</li>
<li>
<b>OSGi</b> - The osgi.jar was used to build org.apache.derby.osgi.EmbeddedActivator.</li>
<li>
<b>Compiler</b> - The 1.4.2_12-b03 javac was used to compile all
classes except for the JDBC4 drivers. The JDBC4 driver classes were compiled
using the 1.6.0-b105 javac.</li>
<li>
<b>JSR 169</b> - J2ME support was built using java.sun.com/j2me (j2me_cdc_fp-1_0_2).</li>
</ul>
</blockquote>
</body>
</html>