On 12/24/2011 11:13 PM, Lie Ryan wrote:
Querying .lastrowid is pretty much safe as long as you don't use a
single cursor from multiple threads. The .lastrowid attribute belongs to
a cursor, so write operations from one cursor would not affect the
.lastrowid of other cursors.
However, note that
Lie Ryan lie.1296 at gmail.com writes:
In python-sqlite, the rowid of the
last insert operation can be queried using cursor.lastrowid. Therefore,
you can query the lastrowid, right after the insert, to find the primary
key of the value you had just inserted. So, in code:
...
cur =
On Sat, Dec 24, 2011 at 9:57 AM, Monte Milanuk memila...@gmail.com wrote:
Lie Ryan lie.1296 at gmail.com writes:
In python-sqlite, the rowid of the
last insert operation can be queried using cursor.lastrowid. Therefore,
you can query the lastrowid, right after the insert, to find the primary
On 12/25/2011 01:57 AM, Monte Milanuk wrote:
Lie Ryanlie.1296at gmail.com writes:
Be careful that in multithreaded program, each thread should have their
own cursors, or otherwise another thread could possibly do another
insert before you can query the lastrowid.
okay, this touches on
So... most python-sqlite tutorials concentrate on single tables. The few that
deal with multiple tables and that mention foreign keys and such seem to
demonstrate mainly using hard-coded data instead of parameterized insert queries
into tables with auto-increment primary keys. For the most part
On 12/24/2011 11:07 AM, Monte Milanuk wrote:
So... most python-sqlite tutorials concentrate on single tables. The few that
deal with multiple tables and that mention foreign keys and such seem to
demonstrate mainly using hard-coded data instead of parameterized insert queries
into tables with
