[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] sqlite3_reset and sqlite3_clear_bindings
From:       Bart Smissaert <bart.smissaert () gmail ! com>
Date:       2017-05-28 16:07:14
Message-ID: CABv7ExczLhqckhQgxRqVJxBUdJonnA9wJ1QxH++fOVej=i2nDw () mail ! gmail ! com
[Download RAW message or body]

> I can't think of any cases where these would happen if everything was
working as planned.

I can't think of anything either and this is all fully tested, so I think I
can leave these checks out.

> From what I can see, you're executing a long series of queries, each of
which you expect to return zero or one row.

No, this is moving data from a 2D variant array to a SQLite table, so these
are inserts with parameters.


RBS

On Sun, May 28, 2017 at 4:37 PM, Simon Slavin <slavins@bigfraud.org> wrote:

>
> On 28 May 2017, at 12:14pm, Gwendal Roué <gwendal.roue@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.smissaert@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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[prev in list] [next in list] [prev in thread] [next in thread]