I think the code in the next higher stackframe may be the culprit.
I inserted a new line of code at vbde.c:2374 so it now reads:
if( pOp->p2 ){
assert( i==1 );
sqlite3RollbackAll(db);
db->autoCommit = 1;
}else{
db->autoCommit = i;
if( sqlite3VdbeHalt(p)==SQLITE_BUSY ){
p->pTos = pTos;
p->pc = pc;
db->autoCommit = 1-i;
p->rc = SQLITE_BUSY;
return SQLITE_BUSY;
}
return SQLITE_OK == p->rc ? SQLITE_DONE : p->rc; // my new line
}
return SQLITE_DONE;
And sqlite_step() now returns SQLITE_FULL as I had expected.
On 2/9/07, Dennis Cote <[EMAIL PROTECTED]> wrote:
Jeffrey Rennie wrote:
> Debugging the code:
>
> winWrite returns SQLITE_FULL, which propagates back up the stack to
> vdbeaux.c, line 1270, in function sqlite3VdbeHalt(Vdbe *p):
>
> }else if( rc!=SQLITE_OK ){
> p->rc = rc;
> sqlite3RollbackAll(db);
>
> Which is good, it's putting the SQLITE_FULL return code into p->rc and
> rolling everything back. Good.
>
> But then the function returns SQLITE_OK on line 1337, so sqlite_step
> returns
> SQLITE_DONE.
>
> So indeed, when a COMMIT TRANSACTION fails because there isn't enough
> disk
> space, sqlite_step returns SQLITE_DONE.
>
> Is there a bug filed for this? Has it been fixed in more recent
> releases?
>
Jeffrey,
This is not the problem. The assignment at 1270 is saving the error
return value into the sqlite3_stmt (or vdeb) structure to record the
failure of this statement. The value returned at 1337 simply tells the
caller that this op-code (Halt) executed correctly. This op-code is only
one step in the execution of the statement.
I'm not saying you haven't found a problem with respect to full disks,
but this code is not the culprit. You will need to keep digging.
HTH
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
