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