On Wed, 2013-11-20 at 13:23 +0200, RSmith wrote:
> Hi Tristan,
>
> Do you honestly have a use-case where you do not know whether a transaction
> is going to be writing to the DB or not?
>
> I would imagine the only way this is possible is that you are doing some form
> of select query, and then
On 20 Nov 2013, at 5:03am, Tristan Van Berkom wrote:
> More precisely then, in the case that a read transaction is upgraded
> to a write transaction, either by issuing an INSERT/DELETE command
> or by issuing a nested BEGIN IMMEDIATE command, is it safe to retry
> sqlite3_exec() until SQLITE_BUS
Hi Tristan,
Do you honestly have a use-case where you do not know whether a transaction is
going to be writing to the DB or not?
I would imagine the only way this is possible is that you are doing some form of select query, and then based on the outcome, decide
whether or not to start writing
On Mon, 2013-11-18 at 22:54 -0700, Keith Medcalf wrote:
> >Since I run all of these statements withing transactions (between
> >"BEGIN" statements and "COMMIT" / "ROLLBACK" statements"), my
> >expectation is that SQLITE_BUSY will only ever be returned for
> >the leading "BEGIN" statement.
>
> SQLI
>Since I run all of these statements withing transactions (between
>"BEGIN" statements and "COMMIT" / "ROLLBACK" statements"), my
>expectation is that SQLITE_BUSY will only ever be returned for
>the leading "BEGIN" statement.
SQLITE_BUSY may be returned, for example, if the transaction is attempt
Hi,
The C code that I use with SQLite is pretty well tested and
known to work well so far, but I've ran into some documentation
which leads me to suspect there is a problem with my existing
code, or a problem with the documentation.
>From the documentation: http://www.sqlite.org/c3ref/step.htm
6 matches
Mail list logo
