Berker Peksag added the comment:
Thanks for the report! This is a duplicate of issue 10513. I've pushed a patch
to fix this for 2.7 and 3.5+ in 030e100f048a and 81f614dd8136.
--
components: +Extension Modules
nosy: +berker.peksag
resolution: -> duplicate
stage: -> resolved
status:
Daniel Lenski added the comment:
I agree on the nastiness of this bug. It's been plaguing my production code for
months and I had been at a loss to explain why I've been getting duplicate rows
until I found this SO post:
Gian-Carlo Pascutto added the comment:
I've ran into this as well, when a program that was running correctly with
PostgreSQL turned out to produce garbage with SQLite. Code to reproduce roughly
looks like this:
sel_cursor = conn.cursor()
sel_cursor.execute(SELECT prim_key_id FROM
R. David Murray added the comment:
(Please trim the original message when replying to a tracker issue.)
When I said, that probably means it's a doc issue, I meant that, even if it
is a bug, for backward compatibility reasons we'd have to just document the
behavior. Fixing the bug would then
Jim Carroll added the comment:
Completely understood.
I recently found a workaround. Setting isolation_level to None seems to
mitigate the issue, ie:
db = sq.connect(':memory:', isolation_level=None)
I'm hoping to put some time in scrutinizing the c-api code later this week (as
SQLite
R. David Murray added the comment:
Ah, then I suspect you are getting hit by the 'automatic transaction' feature
of the DB2 API. So it is probably not the commit, but the subsequent implicit
'begin transaction' that is causing the problem. The trick then is to figure
out why that affects
New submission from Jim Carroll:
I reported this to the sqlite mailing list, and the comments I received
suggested the problem may by the python sqlite connector issue, so I'm opening
this as a bug report.
I understand that performing a SELECT and nested COMMIT on the same table is
not
R. David Murray added the comment:
I'd say you have a bug here of some sort, but I'm not sure if it is a doc bug
or a code bug. Commit specifically does *not* reset the cursors, according to
the code, but I'm not even sure what resetting a cursor means :) I've poked
around the sqlite3
-Original Message-
From: R. David Murray [mailto:rep...@bugs.python.org]
Sent: Monday, December 29, 2014 1:08 PM
To: j...@carroll.com
Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns
unexpected results
R. David Murray added the comment:
I'd say you have a bug here
