Oracle 8.1.6 identity sequence problem

modulo2 · **Joined:** Sat Jun 25, 2005 7:38 am **Posts:** 5

I have read the same problem in this thread but no answer was posted:
http://forum.hibernate.org/viewtopic.php?t=943111

Hibernate version: 3.0.5

Mapping documents:

Code:

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>

    <!-- a SessionFactory instance listed as /jndi/name -->
   <session-factory name="foo:/hibernate/SessionFactory">

        <!-- SQL dialact -->
        <property name="dialect">org.hibernate.dialect.OracleDialect</property>

        <!-- DB Connection -->
        <property name="connection.username">trvdb</property>
        <property name="connection.password">trvdb</property>
        <property name="connection.url">jdbc:oracle:thin:@192.168.0.102:1521:ORCL</property>
        <property name="connection.driver_class">oracle.jdbc.driver.OracleDriver</property>

        <!-- C3P0 Connection Pool -->
        <property name="hibernate.connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
        <property name="hibernate.c3p0.max_size">2</property>
        <property name="hibernate.c3p0.min_size">2</property>
        <property name="hibernate.c3p0.timeout">5000</property>
        <property name="hibernate.c3p0.max_statements">100</property>
        <property name="hibernate.c3p0.idle_test_period">3000</property>
        <property name="hibernate.c3p0.acquire_increment">2</property>
        <property name="hibernate.c3p0.validate">false</property>      

        <!-- Miscellaneous Settings -->
        <!-- Echo all executed SQL to standard output -->
        <property name="show_sql">true</property>
        <property name="use_outer_join">true</property>
        <property name="transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
        <property name="dbcp.minIdle">1</property>
        <property name="cache.use_query_cache">true</property>

        <!-- mapping files -->
        <mapping resource="net/dev/fursan/olap/model/pojo/User.hbm.xml"/>
        <mapping resource="net/dev/fursan/olap/model/pojo/Form.hbm.xml"/>
        <mapping resource="net/dev/fursan/olap/model/pojo/Setting.hbm.xml"/>
        <mapping resource="net/dev/fursan/olap/model/pojo/Target.hbm.xml"/>
        <mapping resource="net/dev/fursan/olap/model/pojo/Branch.hbm.xml"/>
        <mapping resource="net/dev/fursan/olap/model/pojo/Company.hbm.xml"/>
        <mapping resource="net/dev/fursan/olap/model/pojo/Customer.hbm.xml"/>

    </session-factory>

</hibernate-configuration>

The following is contents of "User.hbm.xml"
Mapping documents:

Code:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping default-cascade="all">
  <class name="net.dev.fursan.olap.model.pojo.UserDTO" 
         table="OLAP_USR" 
         dynamic-update="true">
    <id name="id" column="USR_ID">
      <generator class="sequence">
        <param name="sequence">OLAP_USR_SEQ</param>
      </generator>
    </id>
    <property name="loginName" column="USR_LGN_NAME"/>
    <property name="fullName" column="USR_FULL_NAME"/>
    <property name="lastLoginDate" type="timestamp" column="USR_LAST_LGN"/>
    
    <set name="accessedForms" 
          table="OLAP_FORM_ACCESS"
          lazy="true"
          cascade="save-update">
      <key column="USR_ID"/>
      <many-to-many column="FORM_ID" 
                    class="net.dev.fursan.olap.model.pojo.FormDTO"/>
    </set>
  </class>
</hibernate-mapping>

Code between sessionFactory.openSession() and session.close():

Code:

    UserDTO user = new UserDTO();
    
    user.setLoginName    ( username );
    user.setFullName     ( getFullNameFromLdap( ldap, param, username ) );
    user.setLastLoginDate( new Timestamp( new java.util.Date().getTime() ) );
    
    session.save( user );

Full stack trace of any exception that occurs: no exceptions

Name and version of the database you are using: Oracle 8.1.6

The generated SQL (show_sql=true):
Debug level Hibernate log excerpt:
I included both here

Code:

DEBUG org.hibernate.jdbc.AbstractBatcher  - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
DEBUG org.hibernate.SQL  - select OLAP_USR_SEQ.nextval from dual
DEBUG org.hibernate.jdbc.AbstractBatcher  - preparing statement
DEBUG org.hibernate.id.SequenceGenerator  - Sequence identifier generated: 1
DEBUG org.hibernate.jdbc.AbstractBatcher  - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
DEBUG org.hibernate.jdbc.AbstractBatcher  - closing statement
DEBUG org.hibernate.event.def.AbstractSaveEventListener  - generated identifier: 1, using strategy: org.hibernate.id.SequenceGenerator
DEBUG org.hibernate.event.def.AbstractSaveEventListener  - saving [net.dev.fursan.olap.model.pojo.UserDTO#1]
DEBUG org.hibernate.engine.Cascades  - processing cascade ACTION_SAVE_UPDATE for: net.dev.fursan.olap.model.pojo.UserDTO
DEBUG org.hibernate.engine.Cascades  - done processing cascade ACTION_SAVE_UPDATE for: net.dev.fursan.olap.model.pojo.UserDTO
DEBUG org.hibernate.event.def.WrapVisitor  - Wrapped collection in role: net.dev.fursan.olap.model.pojo.UserDTO.accessedForms
DEBUG org.hibernate.engine.Cascades  - processing cascade ACTION_SAVE_UPDATE for: net.dev.fursan.olap.model.pojo.UserDTO
DEBUG org.hibernate.engine.Cascades  - cascade ACTION_SAVE_UPDATE for collection: net.dev.fursan.olap.model.pojo.UserDTO.accessedForms
DEBUG org.hibernate.engine.Cascades  - done cascade ACTION_SAVE_UPDATE for collection: net.dev.fursan.olap.model.pojo.UserDTO.accessedForms
DEBUG org.hibernate.engine.Cascades  - done processing cascade ACTION_SAVE_UPDATE for: net.dev.fursan.olap.model.pojo.UserDTO
DEBUG net.dev.fursan.olap.web.action.LoginAction  - Adding user to session
DEBUG net.dev.fursan.olap.model.security.FursanLdap  - getUserAndForms invoked for username=olap
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - flushing session
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - processing flush-time cascades
DEBUG org.hibernate.engine.Cascades  - processing cascade ACTION_SAVE_UPDATE for: net.dev.fursan.olap.model.pojo.UserDTO
DEBUG org.hibernate.engine.Cascades  - cascade ACTION_SAVE_UPDATE for collection: net.dev.fursan.olap.model.pojo.UserDTO.accessedForms
DEBUG org.hibernate.engine.Cascades  - done cascade ACTION_SAVE_UPDATE for collection: net.dev.fursan.olap.model.pojo.UserDTO.accessedForms
DEBUG org.hibernate.engine.Cascades  - done processing cascade ACTION_SAVE_UPDATE for: net.dev.fursan.olap.model.pojo.UserDTO
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - dirty checking collections
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - Flushing entities and processing referenced collections
DEBUG org.hibernate.engine.Collections  - Collection found: [net.dev.fursan.olap.model.pojo.UserDTO.accessedForms#1], was: [<unreferenced>] (initialized)
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - Processing unreferenced collections
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - Scheduling collection removes/(re)creates/updates
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - Flushed: 1 insertions, 0 updates, 0 deletions to 1 objects
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - Flushed: 1 (re)creations, 0 updates, 0 removals to 1 collections
DEBUG org.hibernate.pretty.Printer  - listing entities:
DEBUG org.hibernate.pretty.Printer  - net.dev.fursan.olap.model.pojo.UserDTO{accessedForms=[], loginName=olap, fullName=olap , lastLoginDate=2005-07-31 17:47:56, id=1}
DEBUG org.hibernate.engine.ActionQueue  - changes must be flushed to space: OLAP_USR
DEBUG org.hibernate.event.def.DefaultAutoFlushEventListener  - Need to execute flush
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - executing flush
DEBUG org.hibernate.cache.UpdateTimestampsCache  - Pre-invalidating space [OLAP_USR]
DEBUG org.hibernate.persister.entity.BasicEntityPersister  - Inserting entity: [net.dev.fursan.olap.model.pojo.UserDTO#1]
DEBUG org.hibernate.jdbc.AbstractBatcher  - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
DEBUG org.hibernate.SQL  - insert into OLAP_USR (USR_LGN_NAME, USR_FULL_NAME, USR_LAST_LGN, USR_ID) values (?, ?, ?, ?)
DEBUG org.hibernate.jdbc.AbstractBatcher  - preparing statement
DEBUG org.hibernate.persister.entity.BasicEntityPersister  - Dehydrating entity: [net.dev.fursan.olap.model.pojo.UserDTO#1]
DEBUG org.hibernate.type.StringType  - binding 'olap' to parameter: 1
DEBUG org.hibernate.type.StringType  - binding 'olap' to parameter: 1
DEBUG org.hibernate.type.StringType  - binding 'olap ' to parameter: 2
DEBUG org.hibernate.type.StringType  - binding 'olap ' to parameter: 2
DEBUG org.hibernate.type.TimestampType  - binding '2005-07-31 17:47:56' to parameter: 3
DEBUG org.hibernate.type.TimestampType  - binding '2005-07-31 17:47:56' to parameter: 3
DEBUG org.hibernate.type.LongType  - binding '1' to parameter: 4
DEBUG org.hibernate.type.LongType  - binding '1' to parameter: 4
DEBUG org.hibernate.jdbc.AbstractBatcher  - Adding to batch
DEBUG org.hibernate.jdbc.AbstractBatcher  - Executing batch size: 1
DEBUG org.hibernate.jdbc.AbstractBatcher  - success of batch update unknown: 0
DEBUG org.hibernate.jdbc.AbstractBatcher  - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
DEBUG org.hibernate.jdbc.AbstractBatcher  - closing statement
DEBUG org.hibernate.cache.UpdateTimestampsCache  - Pre-invalidating space [OLAP_FORM_ACCESS]
DEBUG org.hibernate.persister.collection.AbstractCollectionPersister  - Inserting collection: [net.dev.fursan.olap.model.pojo.UserDTO.accessedForms#1]
DEBUG org.hibernate.persister.collection.AbstractCollectionPersister  - collection was empty
DEBUG org.hibernate.event.def.AbstractFlushingEventListener  - post flush

From logs it seems that the value got for sequence is 1, and also it is binded correctly. but the problem when I try to select using any sql query IDE:
SELECT min(usr_id) FROM olap_usr
The result is
-.0000000000000000000000000000000000000000000000000000007
!!!! sometimes it appears as zero, but when I used min the above value appears.

I tried and inserted another user, & I checked the logs & they are correct the identifier is 2, but even when I tried after insertion I begin gettig the following error when I sleect from this table:
SELECT usr_id FROM olap_usr
ORA-01455: Converting column overflows integer datatype

I have a testing server on 9i release 2, this problem never occurs on this DB & the sequence 1, 2 r inserted corectly, I of course switch the dialect in configuration file for oracle 9i.

I also used at first "increment" for this field as no other processes is inserting but I faced the same problem, thats y I switched to sequence trying to avoid but it seems the problem persists.

I should mention also that I just change the dialect without changing the libraryies in my web application, i.e.: I use the following:
classes12.jar, nls_charset12.jar all the time.

I know I should change the libraries when operating Oracle 8.1.6 ut I tried before & didn't work, maybe I have some advice from u guys.

Appriciate yr help.

modulo2 · **Joined:** Sat Jun 25, 2005 7:38 am **Posts:** 5

Maybe the code for creation the schema & sequence will help:

Code:

create sequence OLAP_USR_SEQ
increment by 1
start with 1
maxvalue 999999999
minvalue 1
nocycle
nocache;

Code:

create table OLAP_USR  (
   USR_ID               NUMBER(9,0)                      not null,
   USR_LGN_NAME         VARCHAR2(30)                     not null,
   USR_FULL_NAME        VARCHAR2(50),
   USR_LAST_LGN         DATE,
   constraint PK_OLAP_USR primary key (USR_ID)
);

modulo2 · **Joined:** Sat Jun 25, 2005 7:38 am **Posts:** 5

After search, found that this is bug in oracle with number 2199718.

It simply if in prepared statment from java using timestamp & the next binded element is the id, the id will be corrupted.

I made a work around for this by:
Inserting the row in DB with empty date (timestamp), then I searched for the row -just to make sure the insertion from hibernate will be done- then I updated the date on separate update statment & of course I made hibernate only detect the changes so just update the date not the whole object.

I hope this helps somebody out there :)

modulo2 · **Joined:** Sat Jun 25, 2005 7:38 am **Posts:** 5

The complete oracle bug 2199718 description from metalink:

---------------------------------
Bug No. 2199718
Filed 24-JAN-2002 Updated 02-MAR-2004
Product Oracle Server - Enterprise Edition Product Version 9.0.1
Platform Solaris Operating System (SPARC 32-bit) Platform Version No Data
Database Version 9.0.1 Affects Platforms Generic
Severity Severe Loss of Service Status Closed, Not Verified by Filer
Base Bug N/A Fixed in Product Version 9.2

Problem statement:

CORRUPTED NUMBER COL IF NEXT BIND PARAMETER IS TIMESTAMP (9.2CLIENT->9.1DB)
________________________________________

*** 01/24/02 10:41 pm ***
Implicit evaluation of int column types in a resultset as a String results
in ArrayOutOfBounds Exception.
.
This if you invoke resultSet.getString( columnIndex ) on a column which
has integer data (column type is NUMBER) the implicit conversion in
oracle.sql.NUMBER.toString() fails resulting in ArrayIndexOutOfBounds
exception.
.
Here is a sample stack Trace :
.
java.lang.ArrayIndexOutOfBoundsException
at oracle.sql.NUMBER.toString(NUMBER.java:774)
(OracleStatement.java:3375)
(OracleResultSetImpl.java:434)
at JdbcTest.main(JdbcTest.java:65)
.
This is occurrs only if the client is 9.2 and the db server is 9.0.1 or
9.0.1.2. Here is the matrix
.
Client DB Server Bug Reproduces Driver
9.2 9.2 NO THICK
9.2 9.0.1 YES THICK
9.2 9.0.1.2 YES THICK
.
The bug is simple to reproduce. Create a table with VARCHAR2 and NUMBER
columns, insert some data in it and issue a sql query via jdbc.
.
Uploaded JdbcTest.java, buildclass and runJdbc.sh onto ESS30 under
bug< bugno> dir. Modify the files for your environment. Note that this is a
priority bug.
.
*** 01/24/02 10:49 pm ***
Update this bug reproduces against 8.1.7 as well.
*** 01/24/02 11:25 pm *** (CHG: Sta->16 Asg->NEW OWNER)
*** 01/24/02 11:25 pm ***
langbde screening...
*** 01/25/02 07:38 am *** (CHG: FixBy->9.2HOT DevPri->1)
*** 01/25/02 01:33 pm *** (CHG: Sta->10)
*** 01/25/02 01:33 pm ***
*** 01/25/02 01:53 pm ***
The testcase does not reproduce the bug with the emp table in scott/tiger
schema.
However looking at data in smp_vde_event_occur_details table, the data looks
like following :
.
-0.00E+125
-0.00E+125
15
.
The Column is declared as NUMBER.
*** 01/25/02 01:57 pm ***
Figuring out how those kind of enormous negative number get into the row. This
is still a regression on 901.
*** 01/25/02 02:43 pm ***
This looks similar to bug#979657. But not sure if bug#979657 was fixed in 9.2
or not. From your updates above, it looks like you have used jdbc 9.2 client
to test with different database versions. So this definitely seems to point
to rdbms. I will try to take the testcase from this old bug and give it a try
in 9.2. In the meantime, any further inputs from you will be very helpful.
Thx.
*** 01/25/02 02:46 pm ***
It would be helpful to investigate where the negative value is coming up. Thx.
*** 01/25/02 02:49 pm ***
Continuation from above - are you using oci (jdbc) driver to populate the
table? If so, can you try to use thin and see if the negative values are
inserted?
*** 01/25/02 03:48 pm ***
Using OCI Thick to do both insert, update and select.
*** 01/25/02 04:46 pm ***
Please try to do the following :
- check what value got inserted in the "problem column - severity" in the
v9.2.0 database. I would like to see if this is also a negative zero value.
- If possible, try to replace your the oci driver in your "insert" program
with thin and see if negative value is still inserted.
*** 01/25/02 04:47 pm ***
Reading Bug#979657, it was never fixed. This leads to the hypothesis that a
pl/sql code in our schema might be getting an uninitialized NUMBER which gets
inserted into the table. Checking that hypothesis in our application code path
*** 01/25/02 04:56 pm ***
The pl/sql has properly initialised global constants.
*** 01/26/02 03:56 pm ***
Bugdb was down. So could not update earlier. This is the status till now for
anyone who is following this :
.
There seem to be 2 issues involved here :
#1. The database seems to be accepting negative 0 value which is identical to
the bug#979657. This is also a very large value which causes the
ArrayIndexOutOfBoundsException in the jdbc client.
Verified that this problem was not fixed even in DB V9.2.0 by forcing a
negative insert.

#2. The second problem seems to be that the application is somehow sending
junk value and this is seen from ( as per inputs from filer):
client V920 -> DB V901
It does not happen when
client V901 -> DB V901
client V920 -> DB V920
.
For this I have suggested the following :
#1. add 10046 trace with level 12 to track the values that are getting into
the db.
#2. add a database trigger on the table which can throw an exception when some
junk value is inserted. This might help narrow down the application path
which is causing the problem.
.
More updates will follow...
.

*** 01/26/02 09:09 pm *** (CHG: Sta->16)
*** 01/26/02 09:09 pm *** (CHG: Confirmed Flag->Y)
*** 01/26/02 09:09 pm ***
*** 01/26/02 09:09 pm *** (CHG: Confirmed Flag->N)
*** 01/27/02 07:26 pm ***
Changing the subject to better reflect the core issue (viz :)
corrupted int col during update if next bind parameter is timestamp column
*** 01/28/02 12:28 pm ***
*** 01/28/02 12:37 pm *** (CHG: Sta->11 Asg->NEW OWNER)
*** 01/28/02 12:37 pm *** (CHG: Confirmed Flag->Y)
*** 01/28/02 12:37 pm ***
BDE screening completed.
*** 01/28/02 04:24 pm *** (CHG: Asg->NEW OWNER)
*** 01/28/02 06:02 pm *** (CHG: Asg->NEW OWNER)
*** 01/29/02 12:33 pm ***
Any updates on this bug. This has put on hold all our 9.2->9.1 Testing.
*** 01/29/02 03:37 pm *** (CHG: Asg->NEW OWNER)
*** 01/29/02 03:37 pm ***
The bug seem to be a OCI bug. I am putting a reproducible
OCI testcase which works fine in the MAIN line but fails in
*** 01/29/02 04:01 pm ***
9.0.1 to 9.0.1 is working fine only because the TIMESTAMP implementation
really happened in 9.2
*** 01/30/02 02:58 pm ***
*** 01/30/02 03:00 pm *** (CHG: Asg->NEW OWNER)
*** 01/30/02 03:00 pm *** (CHG: DevPri->2)
*** 01/31/02 12:42 pm ***
The bug is reproducible according to the following matrix:
SERVER VER. CLIENT VER. REPRODUCIBILITY (?)
--------------- ---------------- --------------------
901 901 YES
920 920 NO
901 920 YES
*** 01/31/02 01:52 pm ***
*** 01/31/02 02:37 pm *** (CHG: Asg->NEW OWNER)
*** 01/31/02 11:35 pm ***
*** 02/01/02 01:54 am ***
.
*** 02/01/02 02:28 am ***
*** 02/04/02 08:31 am ***
*** 02/04/02 03:02 pm *** (CHG: DevPri->1)
*** 02/04/02 03:02 pm ***
*** 02/07/02 04:37 am ***
*** 02/07/02 08:20 am ***
FixBy 9.2 is applied since our current 9.2->9.1 functionality is broken. This
effects our product very seriously.
The 9.0.1.x backport is required ASAP.
*** 02/07/02 08:21 am ***
*** 02/07/02 01:38 pm ***
*** 02/07/02 01:40 pm ***
*** 02/12/02 03:25 am *** (CHG: Sta->35)
*** 02/12/02 03:25 am *** (CHG: Fixed->9.2)
*** 02/12/02 03:25 am ***
.
*** 02/12/02 05:35 pm ***
Does this mean we don't need to patch 9.0.1 server ?
Which label in MAIN will have this fix ?
*** 02/13/02 11:16 am *** (CHG: Sta->11)
*** 02/13/02 11:16 am ***
In order to review - we need the following :
1. Main Label in which this was fixed.
2. If this was a 9.2 Client side issue, then we will use the above label
provided and connect to a 9.1 or 9.0.1.2 db and execute the test cases.
3. If this is *not* a client side issue and a backport is required then please
file appropriate backport request and make this as a base bug to that
backport request.
*** 02/13/02 11:22 am ***
*** 02/13/02 12:35 pm *** (CHG: FixBy->9.2HOT)
*** 02/13/02 09:25 pm *** (CHG: Sta->35)
*** 02/13/02 09:25 pm *** (CHG: Fixed->9.2)
*** 02/13/02 09:25 pm ***
(1) This is NOT a client side issue, but server side 9.0.1 issue.
(2) The fix on the server side is available in MAIN label.
(3) The MAIN label in which I worked, this fix existed,
RDBMS_MAIN_SOLARIS_020114
(4) This means you need a patch on 9.0.1.x, yes a backport is required.
(6) Again, this is not a 9.2 bug.
*** 02/14/02 06:15 am ***
.
Thanks for your updates. We will file the backport request.
*** 02/22/02 11:04 am ***
*** 02/26/02 11:50 pm ***
*** 02/27/02 04:13 pm ***
*** 03/04/02 05:08 am ***
*** 03/05/02 02:00 am ***
*** 03/05/02 03:46 am ***
*** 03/05/02 03:46 am ***
*** 03/05/02 09:43 am ***
*** 03/05/02 09:43 am ***
*** 03/05/02 10:53 am ***
*** 03/05/02 10:53 am ***
*** 03/06/02 06:44 am ***
*** 03/06/02 06:44 am ***
*** 03/08/02 02:20 am ***
*** 03/08/02 02:55 am ***
*** 03/08/02 02:55 am ***
*** 03/08/02 08:25 am ***
*** 03/08/02 08:25 am ***
*** 03/08/02 09:40 am ***
*** 03/08/02 09:40 am ***
*** 03/08/02 10:01 am ***
*** 03/08/02 10:01 am ***
*** 03/08/02 08:37 pm ***
*** 03/08/02 08:37 pm ***
*** 03/10/02 09:14 pm ***
]] Updating a NUMBER column and DATE column using any 9.2 OCI client talking
]] to 9.0.1 server corrupted the NUMBER column on UPDATE.
*** 03/11/02 06:10 am ***
*** 03/11/02 06:10 am ***
*** 03/19/02 03:06 pm *** (CHG: Sta->11)
*** 03/19/02 03:06 pm ***
Reopening Since Bug patches fail to install
8.1.7.3_ARU_1476046 fails to install with the following message
.
smpqa lhung 136> sh patch.sh
chmod: WARNING: can't change httpd_error_log
chmod: WARNING: can't change httpd_access_log
chmod: WARNING: can't change httpd.pid
Using /private1/oracle/oracle817/lib as temporary working directory
This procedure assumes that:
- Your current working directory
/private1/oracle/oracle817
is where you have restored this patch archive to.
- You have read the README.* file.
- You have at least 64 Mb available in the following filesystem.
/private1/oracle/oracle817
- You have at least 32 Mb available in following filesystem
/private1/oracle/oracle817/lib
- You have shutdown all database instances under this ORACLE_HOME
before running this script.
- YOU WILL NOT INTERRUPT THIS PROCEDURE!
Are you ready to continue? [N] => Y
This procedure assumes that:
File /private1/oracle/oracle817/lib64/libserver8.a is missing
File /private1/oracle/oracle817/lib64/libserver8.a is not writable
Patch can not be installed.
8.1.7.3 ARU 1472387 fails with the following error
dlsun1796% sh patch.sh
.
Patch Utility: Applying patch 2256402 for 8.1.7.3 on Sun Solaris Unix
.
chmod: WARNING: can't change dbsnmp
chmod: WARNING: can't access runInstaller
chmod: WARNING: can't access JRE
Using /private/oracle/ora817/lib as temporary working directory
.
This procedure assumes that:
- Your current working directory
/private/oracle/ora817
is where you have restored this patch archive to.
- You have read the README.* file.
- You have at least 64 Mb available in the following filesystem.

/private/oracle/ora817
- You have at least 32 Mb available in following filesystem
/private/oracle/ora817/lib
- You have shutdown all database instances under this ORACLE_HOME
before running this script.
- YOU WILL NOT INTERRUPT THIS PROCEDURE!
Are you ready to continue? [N] => Y
Continuing with patch installation
patch.sh: echodo: not found
patch.sh: echodo: not found
patch.sh: echodo: not found
patch.sh: echodo: not found
patch.sh: echodo: not found
*** Starting relinking of new executables
rdbms/lib:ins_rdbms.mk:ioracle
patch.sh: echodo: not found
Errors occurred during relink of ioracle
Deinstalling patch...
patch.sh: echodo: not found
patch.sh: echodo: not found
patch.sh: echodo: not found
Fix error and try again
*** 03/20/02 12:56 am *** (CHG: Sta->35)
*** 03/20/02 12:56 am *** (CHG: Fixed->9.2)
*** 03/20/02 12:56 am ***
*** 03/20/02 08:52 pm ***
Setting PATH to contain ${ORACLE_HOME}/bin caused the patch 2256402 to apply
successfully.
*** 04/05/02 12:02 am ***
*** 04/05/02 11:29 am ***
*** 04/16/02 10:48 pm ***
*** 05/03/02 02:59 pm ***
*** 05/04/02 05:29 pm ***
*** 05/04/02 05:29 pm ***
*** 05/06/02 05:13 pm ***
*** 05/06/02 05:21 pm ***
*** 05/06/02 06:32 pm ***
*** 05/06/02 06:33 pm ***
*** 05/07/02 03:11 am ***
*** 05/07/02 03:11 am ***
*** 05/07/02 05:52 am ***
*** 05/07/02 06:01 am ***
*** 05/08/02 04:01 am ***
*** 05/08/02 04:11 am ***
*** 06/03/03 01:53 am *** (CHG: FixBy->9.2)
*** 06/03/03 01:53 am *** (CHG: FixBy->9.2HOT)
*** 06/03/03 01:55 am ***
*** 08/20/03 11:53 am *** (CHG: Sta->93)
*** 08/20/03 11:53 am ***
*** 02/27/04 05:28 am ***
*** 02/27/04 05:32 am ***
Rediscovery Information:
.
When updating a number column and a date column using setTimestamp(2, t)
method, if the updated number column data is bad, then it could be this bug.
.
Workaround:
.
Insert only the number column (do not include date column).

Release Notes:
.
]]When updating a number column and a date column using setTimestamp(2, t)
]]method, the number column got updated with bad data.
*** 03/01/04 02:54 am ***
*** 03/01/04 12:03 pm ***
*** 03/02/04 08:25 am ***
*** 03/02/04 04:21 pm ***
*** 03/02/04 08:52 pm ***
*** 03/02/04 08:52 pm ***

---------------------------------