If you use INTEGER PRIMARY KEY, that column becomes your rowids; this does not create a new, separate column in addition to the rowid column.
-----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Abhinav Upadhyay Sent: Thursday, August 11, 2011 2:06 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Use of VACUUM On Thu, Aug 11, 2011 at 11:15 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 11 Aug 2011, at 6:35pm, Abhinav Upadhyay wrote: > >> The documentation page of the VACUUM command says that "The VACUUM >> command may change the ROWIDs of entries in any tables that do not >> have an explicit INTEGER PRIMARY KEY." So what are the possible cases >> in which the ROWIDs might change ? > > Not documented. So even if someone told you what they were in this version of SQLite, there might be other reasons in the next version. Theoretically it might renumber rows to close up gaps in the AUTOINCREMENT. That makes sense. > As it says, to stop it all you need to do is declare one of the columns as INTEGER PRIMARY KEY. Once you do that it assumes that you might be referring to those values elsewhere and won't change them. Indeed, I am using the ROWID as a reference in another table. Actually I have an FTS table and I don't really want to create an explicit column for storing the IDs, as I am afraid that matches from the ID column could affect the quality of search results. But if this is the only option, then I guess I need to give it a try. I might give this column a weight of 0.0 so that it doesn't create noise in the search results. Thanks Abhinav _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
