Keith Medcalf Sent: Monday, December 18, 2017 2:31 PM
...snipped a lot...
>>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 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 if the insert statement was step'd, then how is it that it has not been
>executed? Is the code more like:
It *has* been executed successfully. All of the statements are step'd
regardless of the result of sqlite3_column_count(). The assertion still fails.
...snip...
>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.
*The insert did run to correct completion*. There aren't any transactions,
only a rogue num_col > 0 post-condition that throws an error. That's the
thing I'm trying to get around; I'm trying to get sqlite3_column_count() > 0
from a SQL statement that effects an insert.
----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may
contain information that is privileged, confidential and/or proprietary and
subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer. If you are not the intended
recipient, please delete this message.
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
