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. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
