On Wed, Jan 12, 2011 at 10:07:36PM +0000, Simon Slavin wrote: > On 12 Jan 2011, at 9:57pm, Max Vlasov wrote: > > Simon, your reply led me to the following sequence: > > - I know the rowid of the record I'm changing. I remember all integers (and > > all other data) I'm going to change in the Update query (it' comparatively > > easy task) > > - I check this rowid after the change. If it exists, the record did not > > change the rowid and if it does not I form SELECT .. where rowid= or > > rowid=.. containing all the integers I used and compare the rest of the data > > only with this result set. If there's only single match, this is the answer, > > but if not ... I should think about it :) > > > > Does it sound reasonable? > > It will deal with most cases, but it can still be fooled by creative > use of TRIGGERs, or by bad coincidences in the numbers stored. A > question worth asking might be why you need to maintain these rowids. > If you're just letting your user change whatever data they want, why > are you bothering to keep track of rowids ?
That's my view as well. If you're not in control over what the DB itself is doing (through triggers, for example) or what the user is doing (you're given them too much rope) then you can't reliably detect rowid changes (assuming the DB allows them). Assuming this is for a generic data browser type application, I'd say: a) don't show rowids to users, b) on every update re-run the query that produced the rows displayed to the user and refresh the display. If you can guarantee that the rowid won't change then you can skip (b) and instead just do a query for the modified row to get its new column values. If you can at all help it, then disallow arbitrary rowid changes. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
