On Thu, Jan 13, 2011 at 12:21 AM, Simon Slavin <slav...@bigfraud.org> wrote:
> > On 12 Jan 2011, at 9:02pm, Max Vlasov wrote: > > > It's about the utility, when the data is presented with a grid and every > > cell of opened db and * fields of table can be edited.. I'm aware that my > > own actions can lead to constraint failure, but even for a legitimate > change > > I currently can not point to the same record, and even if I could (data > in > > this case is simply cached) I would not do this next time since this > record > > after this change have another .rowid and it's not possible to format new > > "update where rowid=" query correctly. > > Ah, okay. You have to have access to the value that was stored in the cell > before it was changed. > > You can pre-scan the columns of a table to figure out which ones are likely > to be useful because they're UNIQUE. If you don't find one, then use > 'rowid'. But I don't think there's a simple perfect solution for this. You > are in the position of needing to reread the record you just changed to find > out if change they made to one column TRIGGERed some other change to that > record. > > 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? Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
