> Well, assuming that your > SELECT is selecting the rows you mean to UPDATE or INSERT ...
Also assuming that - all data necessary for these statements can fit into sqlite's cache; - several instances of your application cannot be executed in parallel (otherwise you have to do a special treatment for SQLITE_BUSY return value); And finally could you say it once more: what is the benefit from doing select first and then insert/update as opposed to just insert/update without select? I see that in your case insert/update could be executed faster, without disk I/O, but if we look at them combined what's the difference? Pavel On Wed, Sep 30, 2009 at 10:02 AM, Scott Hess <sh...@google.com> wrote: > Since SQLite is an embedded database, it generally does not pay to > count statements, unless they add additional disk I/O. You can code > like this: > > BEGIN > SELECT ... > if (select results A) > INSERT ... > else > UPDATE ... > END > > and it will be about as fast as either the INSERT or the UPDATE run > independently. This is because the INSERT or the UPDATE will have to > read in all the pages the SELECT would have read in, so the SELECT is > essentially free (just a small cost in CPU). Well, assuming that your > SELECT is selecting the rows you mean to UPDATE or INSERT ... > > -scott > > > On Tue, Sep 29, 2009 at 7:20 PM, Sam Carleton > <scarle...@miltonstreet.com> wrote: >> The function is given a collection of data that needs to be either >> insert or update into the database. One options would be to use >> INSERT OR REPLACE INTO, but the desire is not to remove N add when it >> is an update, but simply do an update using the rowid. All the new >> items that need to be inserted won't have a rowid. >> >> Is it possible to have two different prepare statements at one time; >> one for insert and another for update. Then check each piece of data >> for a rowid to determine which approach to use. Once it is all done, >> clean up both prepare statement. >> >> Sam >> _______________________________________________ >> 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
