I don't think that this is something that's even supported by the
database wrt sequences. In any way, doing a:
SELECT max(id) FROM tablename;
Isn't that much of a deal, is it?
On 05 May 2007, at 19:43, David HM Spector wrote:
Here's an interesting problem... in a perfect world, the ID
sequence for
a primary key in a table should increase (usually) monotonically, and
always be under the control of the DB. However, if for whatever
reason,
you have to edit a table or reset the table without manually resetting
the sequence, you will most likely eventually get duplicate key errors
when you try to insert rows into your table. Coding around this by
catching the duplicate key error is problematic because you don't know
what the current highest id in the table actually is..
Right now you can use SequenceValue() to find out the current and
presumed-next value in the sequence, but a new HIGHEST_USED capability
for this method might be useful for being able to reset a table
sequence
at runtime...
(I realize this is sort of asking for forgiveness for tampering
with the
DB .. but it seems like a logical bit of defensive programming, rather
than have to drop tables or write code to re-sequence existing tables
which could have untold numbers of side-effects.)
thoughts..?
David
--
--
--
David HM Spector
[EMAIL PROTECTED]
voice: +1 631.261.5013 http://
www.zeitgeist.com/
New and stirring things are belittled because if they are not
belittled,
the humiliating question arises, 'Why then are you not taking part
in them?'
--
H. G. Wells
___
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn Use what you need - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
___
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
