Re: Changing ROWID

From: Jeff Jacobs <jmjacobs_at_ix.netcom.com>
Date: 11 Jan 1995 01:02:24 GMT
Message-ID: <3evan0$85r_at_ixnews2.ix.netcom.com>


ROWID is the physical address of a row. It is absolutely guaranteed for the duration of a transaction.

Beyond that, you shouldn't depend on it or use it, e.g. you shouldn't have a table hanging around with ROWIDs between transactions.

If you delete a row, and then insert a row with exactly the same (non-ROWID) values, the new row will almost certainly have a different ROWID.

If you exp/imp, you will get new ROWIDs.

If you create a new table via CREATE AS, the ROWIDs in the *new* table won't match the ROWID in the old table.

An UPDATE will *not* changes a ROWID.

Basic rule is "don't count on ROWID across transactions". ROWID should only be used for fast access within a transaction.

-JJ

 Jeffrey Jacobs & Associates
 Oracle CASE Consulting and Training
 951-2 Old Country Road, Suite 119
 Belmont, CA 94002
 Voice: 415-571-7092
 FAX: 800-665-1379
 CompuServe: 76702,456
 Internet: jjacobs_at_well.com
 Internet: jmjacobs_at_ix.netcom.com  

>
>Daniel K M (danielkm_at_aol.com) wrote:
>: We recently had a small controversy around the office about when a ROWID
>: will change for a given row. One camp held forth that ROWIDs were
>: unreliable, and could possibly change even with a simple update. The
>: other camp, pointing to an Oracle DBA manual, indicated that a ROWID
>: remains constant "over the lifetime of the row". The second group
>: believed that the "lifetime of a row" meant the time from when the row was
>: created by an insert, until it was destroyed via a delete.
 

>: Which is right?
 

>: Why I need to know (for the curious):
>: I need to know how to properly handle a "row not found" condition within
>: one of my programs. Should I inform the user that the row has been
>: deleted, or should I try to determine if it still exists, but has been
>: modified in some way?
>
>--
>Kirk Bradley
>Oracle Corporation
>Mainframe and Integration Technologies Group
>
>
Received on Wed Jan 11 1995 - 02:02:24 CET

Original text of this message