Simon, On Tue, Nov 21, 2017 at 4:48 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > > On 21 Nov 2017, at 10:09pm, Jens Alfke <j...@mooseyard.com> wrote: > >>> On Nov 21, 2017, at 1:56 AM, R Smith <rsm...@rsweb.co.za> wrote: >>> >>> That assumes you are not starting from an integer part (like 4000) and >>> hitting the exact same relative insert spot every time, which /can/ happen, >>> but is hugely unlikely. >> >> Not to beat this into the ground, but: it’s not that unlikely. Let’s say you >> sort rows by date. You’ve already got some entries from 2015 in your >> database, and some from 2017. Someone now inserts 60 entries from 2016, and >> to be ‘helpful’, they insert them in chronological order. Wham, this >> immediately hits that case. > > Yes, if you use this method, you do need to renumber them every so often. > You assess this when you’re working out (before + after) / 2, and you do it > using something like the double-UPDATE command someone came up with earlier. > > But that just brings us back to the question of why OP wants to store ID > numbers which might change.
Homework exercise? Stupid requirements? Thank you. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
