OK, thanks, I see now. Will do some timings, but as you guess the slowdown may be negligible.
RBS On Tue, Mar 17, 2015 at 8:08 PM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 17 Mar 2015, at 8:00pm, Bart Smissaert <bart.smissaert at gmail.com> > wrote: > > > OK, but I can find out from sqlite3_errcode after the loop if there was > an > > error, saving all the checks inside the loop. > > Would there be any harm from that? > > From the documentation: > > <https://www.sqlite.org/c3ref/errcode.html> > > "If a prior API call failed but the most recent API call succeeded, the > return value from sqlite3_errcode() is undefined." > > In other words, it's possible for one call within the loop to generate an > error, then the next one to make it impossible to figure that out. > > I know that right now it looks like having an error accumulator function > might be useful, but calls to sqlite3_errcode() execute extremely quickly > because they just pick up a value which was previously set. They won't > slow your program down. It takes longer to call sqlite3_errmsg() but you > only need to do that if there's an error you hadn't predicted. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
