Re: Another question Regarding ROWID being Safe

From: Thomas J. Kyte <tkyte_at_us.oracle.com>
Date: 1996/10/22
Message-ID: <326c2aec.94941168_at_dcsun4>#1/1


On 22 Oct 1996 02:33:11 GMT, srini_v_at_ix.netcom.com(Srinivasa Rao Vaikuntam) wrote:

>In <326C2BF5.C33_at_infosystem.ch> Daniel Klien <klien_at_infosystem.ch>
>writes:
>>
>>Doug Oldmeadow wrote:
>>>
>>> We have been using ROWID as the key condition to apply updates to a
 row
>>> that has been selected for update. The Administrator's concept
 manual
>>> states this is the fastest method to access a particular row. In
 other
>>> words we select our columns plus ROWID, let the user do user stuff,
 then
>>> update where ROWID = fetched ROWID.
>>>
>>> The manual also says that ROWIDs will change when the data is
>>> unloaded/reloaded - ie some event happens that causes the physical
>>> location of the data to change. Recently, someone suggested that we
>>> should not be using ROWID in this way as "it is not safe".
>>>
>>> My question is - Can ROWID change within the scope of a transaction
 ?
>>> Also, if I do not select for update, is the ROWID still guaranteed
 to be
>>> unique, provided I maintain my connection to the database?
>>>
>>> Any input appreciated.
>>>
>>> Doug OHi Doug
>>
>>You must SELECT FOR UPDATE if you want this guarantee.
>>
>>Bye Dan
>
>I retrieve 10 records from the table, and delete 5 of them from the
>table, after checking for some values. Will the ROWID's of the other 5
>change after the delete operation?
>

No, a rowid will not change for a row ever.

A rowid is assigned when a row is inserted. That rowid will remain with that row forever while that row exists in the database. When that row is deleted, that rowid may be reused by some other, newly inserted record.

Thomas Kyte
Oracle Government
tkyte_at_us.oracle.com                          

http://govt.us.oracle.com

  • Check out Oracle Governments web site! ----- Follow the link to "Tech Center" and then downloadable Utilities for some free software...

statements and opinions are mine and do not necessarily reflect the opinions of Oracle Corporation Received on Tue Oct 22 1996 - 00:00:00 CEST

Original text of this message