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
On 12/25/2011 01:57 AM, Monte Milanuk wrote:
Lie Ryan 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 something tha
On Sat, Dec 24, 2011 at 9:57 AM, Monte Milanuk wrote:
> Lie Ryan 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 yo
Lie Ryan 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 = conn.exe
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 au
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 I
