On 28 May 2017, at 12:14pm, Gwendal Roué <gwendal.r...@gmail.com> wrote:
> I personnally call sqlite3_reset before sqlite3_clear_bingings with great > success, but I don't know if the order is relevant or not. It makes more sense to move sqlite3_clear_bindings() to before you set parameters individually, including before the first time you call sqlite3_step(). There’s no need to call it just before sqlite3_finalize(). In fact, if you’re sure your code sets all the parameters in the statement there’s no need to call it at all. On 28 May 2017, at 12:24pm, Bart Smissaert <bart.smissa...@gmail.com> wrote: > If there was a successful sqlite3_step just preceding it could a > sqlite3_reset possibly be unsuccessful? > If there was a successful sqlite3_reset just preceding it could a > sqlite3_clear_bindings possibly be unsuccessful? I can’t think of any cases where these would happen if everything was working as planned. They might happen if something was wrong with your setup. For instance, some buggy part of your program or OS might write over SQLite’s statement record. But if you have code which has been thoroughly tested, and if timing or program space is so critical to you that checking an int to see if it’s SQLITE_OK takes too long, then yes, you might leave the check out. But a single check for an integer’s exact value doesn’t take long. From what I can see, you’re executing a long series of queries, each of which you expect to return zero or one row. After each result you don’t need any other values which might result, so you execute sqlite3_reset(). There’s no problem with this, and it’s a standard way of operating. sqlite3_clear_bindings() is just a quick way of making sure all parameters have legal (if not useful) values. If you’re immediately going to set all the parameters yourself, then there’s no need to do it. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
