Dixon Hutchinson wrote:
The basic problem is that I am getting SQLITE_BUSY on a call to
sqlite3_exec where the SQL passed is simply "COMMIT;"
Notes:
1. This in on a WIN32 platform.
2. There is only one process (the main process) that makes any calls
to sqlite3 for the DB in question.
3. The process is single threaded
4. The process spawns other processes through CreateProcess(),
however the spawned processes do not perform any sqlite3 calls on
the already opened DB.
5. The sequence of steps near the failure are:
1. call sqlite3_exec to format an SQL "UPDATE" to a table.
This call is not enclosed semantically within a
transaction. I understand that internally, sqlite will
create a transaction for that update.
2. start a transaction by calling sqlite3_exec with "BEGIN;"
3. Bind parameters to a previously prepared statement to
perform a SELECT.
4. call sqlite3_step on the statement
5. call sqlite3_column... to retrieve the data from the select
6. call sqlite3_reset on the statement
7. perform steps 3-6 around 5 times. The loop is terminated
when sqlite3_step returns SQLITE_DONE.
8. call sqlite3_reset after sqlite3_step returns SQLITE_DONE.
9. bind some parameters to a previously prepared statement to
perform an INSERT.
10. call sqlite3_step on the statement
11. call sqlite3_reset on the statement
12. call sqlite3_last_insert_rowid on the DB,
13. call sqlite3_exec with "COMMIT;"... This is the call that
fails with SQLITE3_BUSY.
I put a break point in sqliteDefaultBusyCallback to produce the
following stack trace which I think is right before the failure:
sqlite3.dll!sqliteDefaultBusyCallback(void *
ptr=0x009bdf58, int count=0x00000045) Line 276 + 0x8 C
sqlite3.dll!sqlite3InvokeBusyHandler(BusyHandler * p=0x009be038)
Line 303 + 0x15 C
sqlite3.dll!pager_wait_on_lock(Pager * pPager=0x009becf8, int
locktype=0x00000004) Line 1962 + 0x12 C
sqlite3.dll!pager_write_pagelist(PgHdr * pList=0x012660c0) Line 2291
+ 0xb C
sqlite3.dll!sqlite3pager_sync(Pager * pPager=0x009becf8, const char *
zMaster=0x00000000, unsigned int nTrunc=0x00000000) Line 3714 + 0x9 C
sqlite3.dll!sqlite3BtreeSync(Btree * p=0x009be6d0, const char *
zMaster=0x00000000) Line 6588 + 0x13 C
sqlite3.dll!vdbeCommit(sqlite3 * db=0x009bdf58) Line 975 + 0xb C
sqlite3.dll!sqlite3VdbeHalt(Vdbe * p=0x01267e70) Line 1282 + 0x9 C
sqlite3.dll!sqlite3VdbeExec(Vdbe * p=0x01267e70) Line 635 + 0x9 C
sqlite3.dll!sqlite3_step(sqlite3_stmt * pStmt=0x01267e70) Line 223 +
0x9 C
sqlite3.dll!sqlite3_exec(sqlite3 * db=0x009bdf58, const char *
zSql=0x01266d90, int (void *, int, char * *, char * *)*
xCallback=0x00000000, void * pArg=0x00000000, char * *
pzErrMsg=0x0012f1a4) Line 78 + 0x9 C
.
.
.
I don't understand what is locking the DB file. Does a spawned process
(through CreateProcess) inherit all the open file descriptors of the
parent? I do make sure that there are no transactions in progress when
I spawn the children, therefore there should not be any locks on the DB
file, right?
Do you set the inherit handles flag on your CreateProcess call?
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
