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
