 |
IDS Forum
RE: Are rowids always in increasing order?
Posted By: Rajib Sarkar
Date: Friday, 23 April 2004, at 11:13 a.m.
In Response To: Re: Are rowids always in increasing order? (Rajib Sarkar )
--0__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: multipart/related;
Boundary="1__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81"
--1__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: multipart/alternative;
Boundary="2__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81"
--2__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable
Yes for fragmentation, rowids are not generated by default as a fragmen=
t
internally is represented as a "seperate tablespace" and since ROWID is=
a
representation of the logical page offset within a page for a fragmente=
d
table rows in different fragments can potentially have the same ROWID.
That's why when you create the table "WITH ROWIDS" option a special row=
id
index is created which has got the "fragment partnum, page offset and
slot#" to identify the row uniquely in a fragmented table.
That's the reason relying on ROWID is not recommended as
a) it can change -- in IN PLACE ALTER situations, UNLOAD/LOAD etc.
b) fragmented tables don't have ROWIDs by default, but if you create th=
e
rowids, it adds to an overhead of going through the ROWID index to get =
to
the row and also it occupies extra space as its no more "virtual".
HTH
Thanx much,
Rajib Sarkar
Advisory Software Engineer (RAS)
IBM Data Management Group
If we all did the things we are capable of doing, we would literally
astound ourselves. -- T. Edison
=
NormaJean.Sebasti =
an@tellabs.com =
=
To
04/22/2004 07:39 forum.subscriber@iiug.org, =
PM ids@iiug.org, Rajib =
Sarkar/Phoenix/IBM@IBMUS =
=
cc
=
Subj=
ect
RE: Are rowids always in increas=
ing
order? [2869] =
=
=
=
=
=
=
While the technical explanation of rowid is always appreciated, hasn't
it been a pretty well accepted "rule" for some time (possibly around ID=
S
5.0 days or earlier) that applications/scripts/customers should not be
using rowid....rowid is "property" of informix/ibm.... and subject to
change if needed...
wasn't it the rowid that underwent concept change when fragmentation wa=
s
introduced?
i remember many a training class that emphasized customers should not
rely on rowid, it is not guaranteed to stay consistent per version....
Norma Jean
-----Original Message-----
From: rsarkar@us.ibm.com [mailto:rsarkar@us.ibm.com]
Sent: Thursday, April 22, 2004 7:34 PM
To: ids@iiug.org; forum.subscriber@iiug.org
Subject: Re: Are rowids always in increasing order? [2869]
Rowid is of the format 0xLLLLLLSS where L =3D3D logical page offset wit=
hi=3D
n
tablespace and S =3D3D slot# within page.
When the engine starts allocating pages for the table, usually its
contiguous and with increasing offset into the table ..but there maybe =
=3D
a
situation in a table where say there are 5000 pages already allocated f=
=3D
or
the table and there are some holes in the pages i.e. all of the pages a=
=3D
re
not full with rows and potentially more rows can be fitted into the pag=
=3D
es
.then it maybe that a new row is put in page offset 2000 ..then the RO=3D=
WID
will be less than the row residing on page 5000.
U hv to visualize ROWID as a physical representation of a row ..when a =
=3D
user
asks the engine to get a particular row ..it can get the ROWID (from th=
=3D
e
index) and immediately go into the page without doing any further
calculation ...so yes, its right that the ROWID is unique for the lifet=
=3D
ime
of the row IN THE PAGE. In an IN PLACE ALTER situation, when u update t=
=3D
he
row it may be relocated to another page and a new rowid is representing=
=3D
the
row now. ROWID is no internal integer which the engine increments every=
=3D
time a row is inserted ..ROWID is the means for the engine to reach the=
=3D
row
in the quickest possible way ...
HTH
Thanx much,
Rajib Sarkar
Advisory Software Engineer (RAS)
IBM Data Management Group
If we all did the things we are capable of doing, we would literally
astound ourselves. -- T. Edison
=
=3D
"Jean Sagi" =
=3D
<jeansagi@myrealb =
=3D
ox.com> =
=3D
To
Sent by: ids@iiug.org =
=3D
forum.subscriber@ =
=3D
cc
iiug.org =
=3D
Subj=
=3D
ect
Are rowids always in increasing =
=3D
04/22/2004 04:13 order? [2867] =
=3D
PM =
=3D
=
=3D
=
=3D
=
=3D
=
=3D
=
=3D
Hi,
I wonder if anyone one knows if IDS (9.3) asigns rowids in increasing
order?
I mean Always.
In the documentation it i stated that:
"The database server assigns to each row in the rowid column a unique
number that remains stable for the life of the row."
But I haven't found any indication that the numbers asigned to the rowd=
=3D
is
are always choosed in increasing order.
If anyone know, let me know . I'll appreciate it a lot.
Chucho!
Jean Sagi
jeansagi@myrealbox.com
jeansagi@netscape.net
-----------------------------------------
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.
Thank you.
Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
--2__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
<html><body>
<p>Yes for fragmentation, rowids are not generated by default as a frag=
ment internally is represented as a "seperate tablespace" and=
since ROWID is a representation of the logical page offset within a pa=
ge for a fragmented table rows in different fragments can potentially h=
ave the same ROWID. That's why when you create the table "WITH ROW=
IDS" option a special rowid index is created which has got the &qu=
ot;fragment partnum, page offset and slot#" to identify the row un=
iquely in a fragmented table. <br>
<br>
That's the reason relying on ROWID is not recommended as<br>
a) it can change -- in IN PLACE ALTER situations, UNLOAD/LOAD etc.<br>
b) fragmented tables don't have ROWIDs by default, but if you create th=
e rowids, it adds to an overhead of going through the ROWID index to ge=
t to the row and also it occupies extra space as its no more "virt=
ual".<br>
<br>
HTH<br>
<br>
Thanx much,<br>
<br>
Rajib Sarkar<br>
Advisory Software Engineer (RAS)<br>
IBM Data Management Group <br>
<br>
If we all did the things we are capable of doing, we would literally as=
tound ourselves. -- T. Edison<br>
<br>
<img src=3D"cid:10__=3D88BBE4ECDFC14A818f9e8a93df938@us.ibm.com" width=3D=
"16" height=3D"16" alt=3D"Inactive hide details for NormaJean.Sebastian=
@tellabs.com">NormaJean.Sebastian@tellabs.com<br>
<br>
<br>
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td style=3D"background-image:url(cid:20__=3D88BBE4E=
CDFC14A818f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " wid=
th=3D"40%">
<ul>
<ul>
<ul>
<ul><b><font size=3D"2">NormaJean.Sebastian@tellabs.com</font></b><font=
size=3D"2"> </font>
<p><font size=3D"2">04/22/2004 07:39 PM</font></ul>
</ul>
</ul>
</ul>
</td><td width=3D"60%">
<table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">=
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D88BBE4ECDFC14A818f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"=
100%"><img src=3D"cid:30__=3D88BBE4ECDFC14A818f9e8a93df938@us.ibm.com" =
border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">forum.subscriber@iiug.org, ids@iiug.org, Rajib Sarkar/=
Phoenix/IBM@IBMUS</font></td></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D88BBE4ECDFC14A818f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"=
100%"><img src=3D"cid:30__=3D88BBE4ECDFC14A818f9e8a93df938@us.ibm.com" =
border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
</td></tr>
<tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3=
0__=3D88BBE4ECDFC14A818f9e8a93df938@us.ibm.com" border=3D"0" height=3D"=
1" width=3D"58" alt=3D""><br>
<div align=3D"right"><font size=3D"2">Subject</font></div></td><td widt=
h=3D"100%"><img src=3D"cid:30__=3D88BBE4ECDFC14A818f9e8a93df938@us.ibm.=
com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br>
<font size=3D"2">RE: Are rowids always in increasing order? [2869]</fo=
nt></td></tr>
</table>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
<tr valign=3D"top"><td width=3D"58"><img src=3D"cid:30__=3D88BBE4ECDFC1=
4A818f9e8a93df938@us.ibm.com" border=3D"0" height=3D"1" width=3D"1" alt=
=3D""></td><td width=3D"336"><img src=3D"cid:30__=3D88BBE4ECDFC14A818f9=
e8a93df938@us.ibm.com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><=
/td></tr>
</table>
</td></tr>
</table>
<br>
<tt><br>
While the technical explanation of rowid is always appreciated, hasn't<=
br>
it been a pretty well accepted "rule" for some time (possibly=
around IDS<br>
5.0 days or earlier) that applications/scripts/customers should not be<=
br>
using rowid....rowid is "property" of informix/ibm.... and su=
bject to<br>
change if needed...<br>
<br>
wasn't it the rowid that underwent concept change when fragmentation wa=
s<br>
introduced?<br>
<br>
i remember many a training class that emphasized customers should not<b=
r>
rely on rowid, it is not guaranteed to stay consistent per version....<=
br>
<br>
Norma Jean<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: rsarkar@us.ibm.com [<a href=3D"mailto:rsarkar@us.ibm.com">mailto:=
rsarkar@us.ibm.com</a>]<br>
Sent: Thursday, April 22, 2004 7:34 PM<br>
To: ids@iiug.org; forum.subscriber@iiug.org<br>
Subject: Re: Are rowids always in increasing order? [2869]<br>
<br>
<br>
Rowid is of the format 0xLLLLLLSS where L =3D3D logical page offset wit=
hi=3D<br>
n<br>
tablespace and S =3D3D slot# within page.<br>
<br>
When the engine starts allocating pages for the table, usually its<br>
contiguous and with increasing offset into the table ..but there maybe =
=3D<br>
a<br>
situation in a table where say there are 5000 pages already allocated f=
=3D<br>
or<br>
the table and there are some holes in the pages i.e. all of the pages a=
=3D<br>
re<br>
not full with rows and potentially more rows can be fitted into the pag=
=3D<br>
es<br>
.then it maybe that a new row is put in page offset 2000 ..then the RO=3D=
<br>
WID<br>
will be less than the row residing on page 5000.<br>
<br>
U hv to visualize ROWID as a physical representation of a row ..when a =
=3D<br>
user<br>
asks the engine to get a particular row ..it can get the ROWID (from th=
=3D<br>
e<br>
index) and immediately go into the page without doing any further<br>
calculation ...so yes, its right that the ROWID is unique for the lifet=
=3D<br>
ime<br>
of the row IN THE PAGE. In an IN PLACE ALTER situation, when u update t=
=3D<br>
he<br>
row it may be relocated to another page and a new rowid is representing=
=3D<br>
the<br>
row now. ROWID is no internal integer which the engine increments every=
=3D<br>
<br>
time a row is inserted ..ROWID is the means for the engine to reach the=
=3D<br>
row<br>
in the quickest possible way ...<br>
<br>
HTH<br>
<br>
Thanx much,<br>
<br>
Rajib Sarkar<br>
Advisory Software Engineer (RAS)<br>
IBM Data Management Group<br>
<br>
<br>
If we all did the things we are capable of doing, we would literally<br=
>
astound ourselves. -- T. Edison<br>
<br>
<br>
<br>
=
&=
nbsp; &n=
bsp; =3D<br>
<br>
"Jean Sagi" =
=
&=
nbsp; =3D<br>
<br>
<jeansagi@myrealb =
&=
nbsp; =3D<br>
<br>
ox.com> &nb=
sp; &nbs=
p;  =
; =3D<br>
To <br>
Sent by:  =
; ids@iiug.org &=
nbsp; =3D<br>
<br>
forum.subscriber@ &nb=
sp; &nbs=
p; =3D<br>
cc <br>
iiug.org  =
; =
=
=3D<br>
<br>
=
&=
nbsp; &n=
bsp; Subj=3D<br>
ect <br>
=
Are rowi=
ds always in increasing =3D<br>
<br>
04/22/2004 04:13 &nbs=
p; order? [2867] =
=3D<br>
<br>
PM &nbs=
p;  =
; =
=3D<br>
<br>
=
&=
nbsp; &n=
bsp; =3D<br>
<br>
=
&=
nbsp; &n=
bsp; =3D<br>
<br>
=
&=
nbsp; &n=
bsp; =3D<br>
<br>
=
&=
nbsp; &n=
bsp; =3D<br>
<br>
=
&=
nbsp; &n=
bsp; =3D<br>
<br>
<br>
<br>
<br>
<br>
Hi,<br>
<br>
I wonder if anyone one knows if IDS (9.3) asigns rowids in increasing<b=
r>
order?<br>
<br>
I mean Always.<br>
<br>
In the documentation it i stated that:<br>
<br>
"The database server assigns to each row in the rowid column a uni=
que<br>
number that remains stable for the life of the row."<br>
<br>
But I haven't found any indication that the numbers asigned to the rowd=
=3D<br>
is<br>
are always choosed in increasing order.<br>
<br>
If anyone know, let me know . I'll appreciate it a lot.<br>
<br>
<br>
Chucho!<br>
<br>
<br>
<br>
Jean Sagi<br>
jeansagi@myrealbox.com<br>
jeansagi@netscape.net<br>
<br>
<br>
<br>
<br>
<br>
-----------------------------------------<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
The information contained in this message may be privileged <br>
and confidential and protected from disclosure. If the <br>
reader of this message is not the intended recipient, or an <br>
employee or agent responsible for delivering this message to <br>
the intended recipient, you are hereby notified that any <br>
reproduction, dissemination or distribution of this <br>
communication is strictly prohibited. If you have received <br>
this communication in error, please notify us immediately by <br>
replying to the message and deleting it from your computer.<br>
<br>
Thank you.<br>
Tellabs<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
</tt><br>
<i>(See attached file: BDY.RTF)</i><br>
</body></html>=
--2__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81--
--1__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: image/gif;
name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <10__=88BBE4ECDFC14A818f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7
--1__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: image/gif;
name="pic21734.gif"
Content-Disposition: inline; filename="pic21734.gif"
Content-ID: <20__=88BBE4ECDFC14A818f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==
--1__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: image/gif;
name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <30__=88BBE4ECDFC14A818f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7
--1__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81--
--0__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81
Content-type: application/rtf;
name="BDY.RTF"
Content-Disposition: attachment; filename="BDY.RTF"
Content-ID: <54110__=88BBE4ECDFC14A818f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64
e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYwXGZz
d2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFy
c2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xj
b2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMxXHBh
cmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIFxwYXINCldoaWxlIHRoZSB0ZWNobmljYWwgZXhw
bGFuYXRpb24gb2Ygcm93aWQgaXMgYWx3YXlzIGFwcHJlY2lhdGVkLCBoYXNuJ3QgaXQgYmVlbiBh
IHByZXR0eSB3ZWxsIGFjY2VwdGVkICJydWxlIiBmb3Igc29tZSB0aW1lIChwb3NzaWJseSBhcm91
bmQgSURTIDUuMCBkYXlzIG9yIGVhcmxpZXIpIHRoYXQgYXBwbGljYXRpb25zL3NjcmlwdHMvY3Vz
dG9tZXJzIHNob3VsZCBub3QgYmUgdXNpbmcgcm93aWQuLi4ucm93aWQgaXMgInByb3BlcnR5IiBv
ZiBpbmZvcm1peC9pYm0uLi4uIGFuZCBzdWJqZWN0IHRvIGNoYW5nZSBpZiBuZWVkZWQuLi5ccGFy
DQpccGFyDQp3YXNuJ3QgaXQgdGhlIHJvd2lkIHRoYXQgdW5kZXJ3ZW50IGNvbmNlcHQgY2hhbmdl
IHdoZW4gZnJhZ21lbnRhdGlvbiB3YXMgaW50cm9kdWNlZD9ccGFyDQpccGFyDQppIHJlbWVtYmVy
IG1hbnkgYSB0cmFpbmluZyBjbGFzcyB0aGF0IGVtcGhhc2l6ZWQgY3VzdG9tZXJzIHNob3VsZCBu
b3QgcmVseSBvbiByb3dpZCwgaXQgaXMgbm90IGd1YXJhbnRlZWQgdG8gc3RheSBjb25zaXN0ZW50
IHBlciB2ZXJzaW9uLi4uLlxwYXINClxwYXINCk5vcm1hIEplYW5ccGFyDQpccGFyDQpccGFyDQpc
cGFyDQpccGFyDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLVxwYXINCkZyb206IHJzYXJrYXJA
dXMuaWJtLmNvbSBbbWFpbHRvOnJzYXJrYXJAdXMuaWJtLmNvbV1ccGFyDQpTZW50OiBUaHVyc2Rh
eSwgQXByaWwgMjIsIDIwMDQgNzozNCBQTVxwYXINClRvOiBpZHNAaWl1Zy5vcmc7IGZvcnVtLnN1
YnNjcmliZXJAaWl1Zy5vcmdccGFyDQpTdWJqZWN0OiBSZTogQXJlIHJvd2lkcyBhbHdheXMgaW4g
aW5jcmVhc2luZyBvcmRlcj8gWzI4NjldXHBhcg0KXHBhcg0KXHBhcg0KUm93aWQgaXMgb2YgdGhl
IGZvcm1hdCAweExMTExMTFNTIHdoZXJlIEwgPTNEIGxvZ2ljYWwgcGFnZSBvZmZzZXQgd2l0aGk9
XHBhcg0KblxwYXINCnRhYmxlc3BhY2UgYW5kIFMgPTNEIHNsb3QjIHdpdGhpbiBwYWdlLlxwYXIN
ClxwYXINCldoZW4gdGhlIGVuZ2luZSBzdGFydHMgYWxsb2NhdGluZyBwYWdlcyBmb3IgdGhlIHRh
YmxlLCB1c3VhbGx5IGl0c1xwYXINCmNvbnRpZ3VvdXMgYW5kIHdpdGggaW5jcmVhc2luZyBvZmZz
ZXQgaW50byB0aGUgdGFibGUgLi5idXQgdGhlcmUgbWF5YmUgPVxwYXINCmFccGFyDQpzaXR1YXRp
b24gaW4gYSB0YWJsZSB3aGVyZSBzYXkgdGhlcmUgYXJlIDUwMDAgcGFnZXMgYWxyZWFkeSBhbGxv
Y2F0ZWQgZj1ccGFyDQpvclxwYXINCnRoZSB0YWJsZSBhbmQgdGhlcmUgYXJlIHNvbWUgaG9sZXMg
aW4gdGhlIHBhZ2VzIGkuZS4gYWxsIG9mIHRoZSBwYWdlcyBhPVxwYXINCnJlXHBhcg0Kbm90IGZ1
bGwgd2l0aCByb3dzIGFuZCBwb3RlbnRpYWxseSBtb3JlIHJvd3MgY2FuIGJlIGZpdHRlZCBpbnRv
IHRoZSBwYWc9XHBhcg0KZXNccGFyDQoudGhlbiBpdCBtYXliZSB0aGF0IGEgbmV3IHJvdyBpcyBw
dXQgaW4gcGFnZSBvZmZzZXQgMjAwMCAuLnRoZW4gdGhlIFJPPVxwYXINCldJRFxwYXINCndpbGwg
YmUgbGVzcyB0aGFuIHRoZSByb3cgcmVzaWRpbmcgb24gcGFnZSA1MDAwLlxwYXINClxwYXINClUg
aHYgdG8gdmlzdWFsaXplIFJPV0lEIGFzIGEgcGh5c2ljYWwgcmVwcmVzZW50YXRpb24gb2YgYSBy
b3cgLi53aGVuIGEgPVxwYXINCnVzZXJccGFyDQphc2tzIHRoZSBlbmdpbmUgdG8gZ2V0IGEgcGFy
dGljdWxhciByb3cgLi5pdCBjYW4gZ2V0IHRoZSBST1dJRCAoZnJvbSB0aD1ccGFyDQplXHBhcg0K
aW5kZXgpIGFuZCBpbW1lZGlhdGVseSBnbyBpbnRvIHRoZSBwYWdlIHdpdGhvdXQgZG9pbmcgYW55
IGZ1cnRoZXJccGFyDQpjYWxjdWxhdGlvbiAuLi5zbyB5ZXMsIGl0cyByaWdodCB0aGF0IHRoZSBS
T1dJRCBpcyB1bmlxdWUgZm9yIHRoZSBsaWZldD1ccGFyDQppbWVccGFyDQpvZiB0aGUgcm93IElO
IFRIRSBQQUdFLiBJbiBhbiBJTiBQTEFDRSBBTFRFUiBzaXR1YXRpb24sIHdoZW4gdSB1cGRhdGUg
dD1ccGFyDQpoZVxwYXINCnJvdyBpdCBtYXkgYmUgcmVsb2NhdGVkIHRvIGFub3RoZXIgcGFnZSBh
bmQgYSBuZXcgcm93aWQgaXMgcmVwcmVzZW50aW5nPVxwYXINCiB0aGVccGFyDQpyb3cgbm93LiBS
T1dJRCBpcyBubyBpbnRlcm5hbCBpbnRlZ2VyIHdoaWNoIHRoZSBlbmdpbmUgaW5jcmVtZW50cyBl
dmVyeT1ccGFyDQpccGFyDQp0aW1lIGEgcm93IGlzIGluc2VydGVkIC4uUk9XSUQgaXMgdGhlIG1l
YW5zIGZvciB0aGUgZW5naW5lIHRvIHJlYWNoIHRoZT1ccGFyDQogcm93XHBhcg0KaW4gdGhlIHF1
aWNrZXN0IHBvc3NpYmxlIHdheSAuLi5ccGFyDQpccGFyDQpIVEhccGFyDQpccGFyDQpUaGFueCBt
dWNoLFxwYXINClxwYXINClJhamliIFNhcmthclxwYXINCkFkdmlzb3J5IFNvZnR3YXJlIEVuZ2lu
ZWVyIChSQVMpXHBhcg0KSUJNIERhdGEgTWFuYWdlbWVudCBHcm91cFxwYXINClxwYXINClxwYXIN
CklmIHdlIGFsbCBkaWQgdGhlIHRoaW5ncyB3ZSBhcmUgY2FwYWJsZSBvZiBkb2luZywgd2Ugd291
bGQgbGl0ZXJhbGx5XHBhcg0KYXN0b3VuZCBvdXJzZWx2ZXMuIC0tIFQuIEVkaXNvblxwYXINClxw
YXINClxwYXINClxwYXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPVxwYXINCiAgICBccGFyDQogICAgICAgICAg
ICAgIkplYW4gU2FnaSIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID1ccGFyDQogICAgXHBhcg0KICAgICAgICAgICAgIDxqZWFuc2FnaUBteXJlYWxiICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9XHBhcg0KICAgIFxwYXINCiAgICAg
ICAgICAgICBveC5jb20+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgPVxwYXINCiBUbyBccGFyDQogICAgICAgICAgICAgU2VudCBieTogICAgICAgICAg
ICAgICAgICBpZHNAaWl1Zy5vcmcgICAgICAgICAgICAgICAgICAgID1ccGFyDQogICAgXHBhcg0K
ICAgICAgICAgICAgIGZvcnVtLnN1YnNjcmliZXJAICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA9XHBhcg0KIGNjIFxwYXINCiAgICAgICAgICAgICBpaXVnLm9yZyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPVxwYXINCiAgICBc
cGFyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgU3Viaj1ccGFyDQplY3QgXHBhcg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgQXJlIHJvd2lkcyBhbHdheXMgaW4gaW5jcmVhc2luZyA9XHBhcg0K
ICAgIFxwYXINCiAgICAgICAgICAgICAwNC8yMi8yMDA0IDA0OjEzICAgICAgICAgIG9yZGVyPyBb
Mjg2N10gICAgICAgICAgICAgICAgICAgPVxwYXINCiAgICBccGFyDQogICAgICAgICAgICAgUE0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID1c
cGFyDQogICAgXHBhcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9XHBhcg0KICAgIFxwYXINCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgPVxwYXINCiAgICBccGFyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID1ccGFyDQogICAgXHBhcg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICA9XHBhcg0KICAgIFxwYXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPVxwYXINCiAgICBccGFyDQpc
cGFyDQpccGFyDQpccGFyDQpccGFyDQpIaSxccGFyDQpccGFyDQpJIHdvbmRlciBpZiBhbnlvbmUg
b25lIGtub3dzIGlmIElEUyAoOS4zKSBhc2lnbnMgcm93aWRzIGluIGluY3JlYXNpbmdccGFyDQpv
cmRlcj9ccGFyDQpccGFyDQpJIG1lYW4gQWx3YXlzLlxwYXINClxwYXINCkluIHRoZSBkb2N1bWVu
dGF0aW9uIGl0IGkgc3RhdGVkIHRoYXQ6XHBhcg0KXHBhcg0KIlRoZSBkYXRhYmFzZSBzZXJ2ZXIg
YXNzaWducyB0byBlYWNoIHJvdyBpbiB0aGUgcm93aWQgY29sdW1uIGEgdW5pcXVlXHBhcg0KbnVt
YmVyIHRoYXQgcmVtYWlucyBzdGFibGUgZm9yIHRoZSBsaWZlIG9mIHRoZSByb3cuIlxwYXINClxw
YXINCkJ1dCBJIGhhdmVuJ3QgZm91bmQgYW55IGluZGljYXRpb24gdGhhdCB0aGUgbnVtYmVycyBh
c2lnbmVkIHRvIHRoZSByb3dkPVxwYXINCmlzXHBhcg0KYXJlIGFsd2F5cyBjaG9vc2VkIGluIGlu
Y3JlYXNpbmcgb3JkZXIuXHBhcg0KXHBhcg0KSWYgYW55b25lIGtub3csIGxldCBtZSBrbm93IC4g
SSdsbCBhcHByZWNpYXRlIGl0IGEgbG90LlxwYXINClxwYXINClxwYXINCkNodWNobyFccGFyDQpc
cGFyDQpccGFyDQpccGFyDQpKZWFuIFNhZ2lccGFyDQpqZWFuc2FnaUBteXJlYWxib3guY29tXHBh
cg0KamVhbnNhZ2lAbmV0c2NhcGUubmV0XHBhcg0KXHBhcg0KfQ==
--0__=88BBE4ECDFC14A818f9e8a93df938690918c88BBE4ECDFC14A81--
Messages In This Thread
- Are rowids always in increasing order?
Jean Sagi -- Thursday, 22 April 2004, at 7:13 p.m.
- Re: Are rowids always in increasing order?
Rajib Sarkar -- Thursday, 22 April 2004, at 8:34 p.m.
- RE: Are rowids always in increasing order?
NormaJean.Sebastian@tellabs.com -- Thursday, 22 April 2004, at 10:44 p.m.
- RE: Are rowids always in increasing order?
Rajib Sarkar -- Friday, 23 April 2004, at 11:13 a.m.
- Re: Are rowids always in increasing order?
Madison Pruet -- Thursday, 22 April 2004, at 9:45 p.m.
- Re: Are rowids always in increasing order?
vze2qjg5@verizon.net -- Friday, 23 April 2004, at 11:53 a.m.
IDS Forum is maintained by Administrator with WebBBS 5.12.
|
|
