ROW ID

Is there a hidden column in a table that contains a
unique value for a particular row.
In Oracle there is a ROWID
In DB2 there is RRN
Is there an equivalent value in SQL 2000No. Not unless you create one. In SQL Server you can use the Identity
property to create a rowid...
Now if you're looking for the internal row locator - which non-clustered
indexes use to point to the associated data row - then there are two types
within SQL Server - the clustering key (if the table is clustered) and a
fixed rowid (if the table does not have a clustered index - therefore it's a
heap). The clustering key is easily accessibly. The fixed rowid as part of a
heap consists of an 8 byte key. 2 bytes for the file, 4 bytes for the page
id and 2 bytes for the row offset slot number.
OK - that might be too much information... :)
hth,
kt
--
Please reply only on the newsgroups! Include dml/ddl, when possible.Thanks
Kimberly L. Tripp
President, SYSolutions, Inc. www.SQLSkills.com
Principal Mentor, Solid Quality Learning www.SolidQualityLearning.com
"Roy Wennerod" <rwennerod@.hotmail.com> wrote in message
news:032801c37eda$70fec160$a401280a@.phx.gbl...
> Is there a hidden column in a table that contains a
> unique value for a particular row.
> In Oracle there is a ROWID
> In DB2 there is RRN
> Is there an equivalent value in SQL 2000|||"Roy Wennerod" <rwennerod@.hotmail.com> wrote in message
news:032801c37eda$70fec160$a401280a@.phx.gbl...
> Is there a hidden column in a table that contains a
> unique value for a particular row.
> In Oracle there is a ROWID
> In DB2 there is RRN
> Is there an equivalent value in SQL 2000
No there is not.
David|||"Hal Berenson" <haroldb@.truemountainconsulting.com> wrote in message
news:OeQq6h9fDHA.2172@.TK2MSFTNGP09.phx.gbl...
> The problem with exposing the internal pointers (whatever a product may
call
> them) is that it makes it impractical to move rows around in the database
> without breaking applications. As long as applications don't have access
to
> this physical pointer, you can do things like split a node in a clustered
> index, or perform an on-line reorganization, and never break an
application.
> That's why SQL Server, like other products that had their origins in the
> so-called second generation of rdbms products, does not expose them. The
> products that have their origins in the first generation, DB2, Rdb, and
> Oracle do expose these pointers.
> It is highly unlikely that SQL Server will ever expose the internal
> pointers. There were extensive discussions on this topic during
development
> of SQL Server 7.0, and the team (including those from Rdb who were fond of
> DBKEYs) concluded that exposing the internal pointers would be a mistake.
> To expose them and retain the online reorganization capabilities would
> require that the pointers be virtualized. And if you virtualize them then
> the implementation is no different then the user defining a new column
(with
> an index), or using an existing key column. So SQL Server's architecture
> relies on not exposing the physical pointers to the user.
Can't you have your cake and eat it too with the sql99 row_number()
function? :)
There's an army of users who are begging for this!:)|||Hal,
Thank you for the quick response...perhaps I should ask for what I am
trying to accomplish.
I have a table that has one nvarchar column. I need to display the
results in the order in which the data was entered into the database.
I was thinking I could use rowid or an equivalent. Any ideas.
Thanks in advance.
"Hal Berenson" <haroldb@.truemountainconsulting.com> wrote in message news:<OeQq6h9fDHA.2172@.TK2MSFTNGP09.phx.gbl>...
> The problem with exposing the internal pointers (whatever a product may call
> them) is that it makes it impractical to move rows around in the database
> without breaking applications. As long as applications don't have access to
> this physical pointer, you can do things like split a node in a clustered
> index, or perform an on-line reorganization, and never break an application.
> That's why SQL Server, like other products that had their origins in the
> so-called second generation of rdbms products, does not expose them. The
> products that have their origins in the first generation, DB2, Rdb, and
> Oracle do expose these pointers.
> It is highly unlikely that SQL Server will ever expose the internal
> pointers. There were extensive discussions on this topic during development
> of SQL Server 7.0, and the team (including those from Rdb who were fond of
> DBKEYs) concluded that exposing the internal pointers would be a mistake.
> To expose them and retain the online reorganization capabilities would
> require that the pointers be virtualized. And if you virtualize them then
> the implementation is no different then the user defining a new column (with
> an index), or using an existing key column. So SQL Server's architecture
> relies on not exposing the physical pointers to the user.
> --
> Hal Berenson, SQL Server MVP
> True Mountain Group LLC
>
> "bob" <bob@.hotmail.com> wrote in message
> news:03a701c37edc$800c23d0$a401280a@.phx.gbl...
> > there is a ROWID for each row in SQL Server too, just like
> > in Oracle but it is for only internal use, not exposed to
> > the users for querying. You can't see it or query it as an
> > implicit column. I don't know if MS is planning to expose
> > ROWID to the user querying in future versions of sql
> > server.
> >
> > You have to define a business key as a unique key or use
> > IDENTITY column to uniquely identify each row in a table.
> >
> > >--Original Message--
> > >Is there a hidden column in a table that contains a
> > >unique value for a particular row.
> > >
> > >In Oracle there is a ROWID
> > >
> > >In DB2 there is RRN
> > >
> > >Is there an equivalent value in SQL 2000
> > >.
> > >