On 11/1/16 7:01 AM, Simon Slavin wrote:
On 1 Nov 2016, at 10:45am, R Smith <rsm...@rsweb.co.za> wrote:
D - Horrible if you up some key value significantly and then update it back
down, because there is no way the Autoinc value should *EVER* be able/allowed
to come back down. It's a one-way street.
This is an additional argument for not allowing UPDATE to change an "INTEGER PRIMARY
KEY AUTOINCREMENT" value.
Which, according to GB, is what some other SQL engines do: attempts to change a
value in that column using UPDATE always generate an error. I didn't know
that. I looked it up. Apparently Microsoft's SQLSERVER blocks it, but I was
unable to find anything mentioning how any of the other big SQL engines handles
it.
Simon.
MySQL sets the increment to max+1 ever used, and uses the auto=increment
value any time you try to set the field to 0 (other values get written
at provided, assuming they are unique). This can be handy when you
create the table schema and then restore data that was saved from a
previous version of the table, The restored data has values for the
field, which you want to be used, and may not use every number as some
records might have been deleted. If it strictly just used the
auto-increment value then any use of that as a foreign key in some other
table gets broken.
--
Richard Damon
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
