Instruction
-----------

This directory contains refresh of DB2 Everyplace Database Edition Version 7.2.1.
This refresh assumes DB2 Everyplace Database Edition or Enterprise Edition Version 7.2.1 has been installed.
Unzip DB2Everyplace_721_Refresh.zip and copy needed files to the corresponding folders.


Defects/problems fixed since DB2 Everyplace V7.2.1
--------------------------------------------------

  DB2 Everyplace didn't accept long connection path
  Win32 UNICODE didn't work on Win9x/ME
  JDBC Driver: DB2eDriver class did not handle invalid URLs properly
  java.sql package for Palm OS JDBC Driver: DriverManager getConnection method did not handle exceptions 
         thrown by DB2eDriver connect method, SQLWarning getNextWarnings method did not handle null case
  Palm OS JDBC Driver: DB2eBridge class had memory leaks
  Transaction shadow file grew unlimitedly and not cleaned up at database disconnect time
  DB2 Everyplace allowed allocation of statement handle using connection handle that was not connected
  DB2 Everyplace crashed when trying to set autocommit on second connection
  C applications could not fetch all rows in result set using fetch next (scrollable cursor fix)
  DB2 Everyplace crashed when UPDATE was executed using single-column index for searching
    while dirty-bit index existed

  CLI calls were not thread-safe (CLI calls are now thread-safe only on WinCE and Win32)
  DELETE statement may get into an infinite loop (data depending)
  UPDATE/DELETE statements fail for non-null-terminated string (parameter markers)
  Inserting a row with a date column via default value fails
  Creating a table T may create a file "DSY_eT" which should have been "DSY_T"
  DB2 Everyplace (JDBC driver) on CrEme JVM crashed on insert with parameter markers
  "SELECT DISINCT ..." query may return wrong answer set
  Data corruption due to multiple statement handles (see description below)

Data corruption problem
-----------------------

A data corruption problem may occur when the application executes a
prepared SELECT statement which does not create a temporary table
(using one statement handle) and the tables referenced in the SELECT
statement have been modified via a different statement handle.  This
is exemplified by the following pseudo-code:

  step 1: SQLPrepare(handle1, "SELECT * FROM T" ..)
  step 2: SQLExecute(handle1)
  step 3: SQLFetch(handle1)
  step 4: SQLExecDirect(handle2, "INSERT INTO T VALUES (10)" ..)
  step 5: SQLExecute(handle1)

In step 1, the application prepares a simple SELECT statement against table T.
In step 2, the application executes the prepared statement using statement handle "handle1".
In step 3, the application fetches a row.
In step 4, the application inserts a row into the SAME table via a different statement handle.
In step 5, the application re-executes the prepared statement using "handle1".

In this situation, unfortunately, the table T becomes corrupted.  This
data corruption problem has been fixed in this patch, and will be
integrated into a future release.


Clarification on the use of multiple statement handles
------------------------------------------------------

An application may use multiple statement handles in accessing and
modifying a DB2 Everyplace database.  This note clarifies under what
circumstances the use of multiple statement handles would not work due
to the limitation of the DB2 Everyplace database engine.

Affected are SELECT queries (regardless whether they are executed
directly or prepared) that use an index for traversing the data and
have not been pre-executed.  That is, the query result set will not be
stored in a temporary table from which all the fetch statements can be
served. Statement handles representing such a SELECT query and having
an open cursor against the result set can become invalid by other
statements (such as DELETE) executed on a different handle if the
latter would endanger the correct navigation through the index for
processing the SELECT query.  These affected SELECT queries have to be
re-executed (not necessarily re-prepared.)

The followings are examples of INSERT, DELETE and UPDATE statements
that will invalidate other statement handles (of SELECT queries).

(a) INSERT:

A successful insert statement will invalidate all other statement
handles that are SELECT statements (accessing the modified table).

Example:

	 (handle 1): SELECT col1 FROM T WHERE pk1 = ? and pk2 = ?;
	 (handle 2): INSERT INTO T VALUES (...);

Here we assume that pk1 and pk2 are the primary key columns.  The
SELECT query uses the primary key index to access the data.  The
INSERT alters the primary key index, and as a result the first
handle needs to be invalidated.  Applications should re-execute
the SELECT query.

(b) DELETE:

Works similarly as the INSERT case.

Example:

     (handle 1): SELECT col1, col2, col3 FROM T WHERE pk1 = ? ORDER BY col3;
     (handle 2): DELETE FROM T WHERE pk1 = ? and pk2 = ?;

Here we assume that table T has an index on (pk1, col3) so that no
temporary table will be created for the result set of the SELECT
query.  Like in the INSERT case, applications should re-execute the
SELECT query.

(c) UPDATE:

Example:

	 (handle 1): SELECT col1, col2, col3 FROM T WHERE pk1 = ?;
	 (handle 2): UPDATE T SET col3 = ? WHERE pk1 = ? AND pk2 = ?;

Here there is no index on col3, which is the only column in the
SET statement. So the SELECT statement handle will not be invalid.
In the following example, however, we create an index on
col3 and make the processing of the SELECT statement perform a
scan on it.

Example: 
	 (handle 0): CREATE INDEX idx ON T (col3);
	 (handle 1): SELECT col1, col2, col3 FROM T WHERE pk1 = ?;
	 (handle 2): UPDATE T SET col3 = ? WHERE pk1 = ? AND pk2 = ?;

The UPDATE statement would in this case invalidate the SELECT handle.
Like in the INSERT case, applications should re-execute the SELECT
query.

In summary, applications should re-execute a SELECT statement if other
statement handles modify the indexes referenced in the SELECT statement.
Otherwise, DB2 Everyplace may return an error, return incorrect answer
or behave unpredictably.