Hi Keith > UPDATE user SET a=1,b=2,c=3 WHERE a||b||c!=1||2||3;
It seems to me that this is not reliable. Think the the following text values: a='12' b='34' c='56' If you want to update these values to: a='1' b='2345' c='6' Then your statement would not update because '123456' = '123456'. Greetings Am 25.11.2012 17:04, schrieb Simon Slavin: > > On 25 Nov 2012, at 10:46am, Keith Chew <keith.c...@gmail.com> wrote: > >> I found that when an update SQL is issued against a table, the WAL file >> gets updated with the new record, even though the record is exactly the >> same as the current record. >> >> [snip] >> >> Is there a specific reason for this? Is there a way to improve this by not >> inserting the record into the WAL file if the final record is not changed? > > I think it would take SQLite a lot of time to read every row to see whether > the UPDATE command will change it before generating the new entry. Most > people's code wouldn't issue such a command under those circumstances. > Richard's suggesting of > >> UPDATE user SET user_name='Keith' WHERE user_name!='Keith'; > > is what you're asking for. With that many columns (which is unusual, > generally you should be able to keep an entire schema in your head) you can > either check them one by one, or concatenate them all together and check to > see that the long concatenation hasn't changed: > > UPDATE user SET a=1,b=2,c=3 WHERE a||b||c!=1||2||3; > > I seem to remember that this is a database where you have every column, of 40 > to 50 columns, indexed. This is also unusual, and not something that SQLite > is optimized for, and you're going to get unusual results from it. > > Simon. > _______________________________________________ > 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
