On Monday, 18 December, 2017 11:35
>Keith Medcalf Sent: Monday, December 18, 2017 1:07 PM
>To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
>Subject: Re: [sqlite] Odd question
>>>I investigated a further while exploring some of the list
>>>suggestions. The app halts with an error unless
>>>sqlite3_column_count() > 0. That means I misspoke when I mentioned
>>>that the sql statement needed to return at least one row. I’m not
>>>sure if that makes a difference, though.
>> That makes a *huge* difference. sqlite3_column_count() is
>available after the prepare and before the first step.
>Yes, the sqlite3_column_count() call happens after prepare() and
>before step().
>>This means that the statement can be cancelled BEFORE it is executed
>(step'ed). "returns no rows" can only be determined by running
>(step'ing) the statement and requires the statement to be both
>prepared and run (and that it returns SQLITE_DONE with no
>SQLITE_ROW).
>Right, all of the statements are step'd regardless of the result of
>sqlite3_column_count(). SQLITE_DONE is returned from the first
>step() for insert queries.
>>In the former case all statements which are not select/pragma
>statements returning data do not have to be run.
>All the statements are run, the check for column count happens
>further downstream
>>In the latter case, all statements will be run and you will get the
>"no data was returned" if no data was returned.
>Yes, all statements are run but the error comes from the fact that
>sqlite3_column_count() == 0
>In pseudocode, it's
>prepare("insert...") //okay
>int num_col = sqlite3_column_count() //okay
>step() until sqlite_done //okay
>assert(num_col > 0) // blows up here, even though the query was
>successful
>So effectively I need sqlite3_column_count() > 0 in order to bypass
>the faulty assertion.
>Thanks for your help in pushing me to think about it and describe it
>more clearly- even if we don't find a solution it's a helpful
>conversation.
So if the insert statement was step'd, then how is it that it has not been
executed? Is the code more like:
prepare(BEGIN)
step(BEGIN)
prepare(INSERT)
num_col = ....
(step() until sqlite_done)
prepare(ROLLBACK)
step(ROLLBACK)
Because if the INSERT is stepped until done, then UNLESS each statement (or
group of statements) is taking place within an explicit transaction that is
then rolled back, the INSERT must have run to completion and been committed,
and the data MUST have been inserted ... notwithstanding the assert failure.
As far as I can tell, the only way this would not be true is if the statement
were run inside an explicit transaction which was "aborted" by de-rugging
before it was committed.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
