Jeffrey Rennie wrote:
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.
Jeffrey,
I'm a little suspicious of your fix. You said you are using version
3.3.4 and it only has the older version of sqlite_step which is
documented as only returning a subset of the sqlite error codes at
http://www.sqlite.org/capi3ref.html#sqlite3_step
In the lagacy interface, the return value will be either
SQLITE_BUSY, SQLITE_DONE, SQLITE_ROW, SQLITE_ERROR, or SQLITE_MISUSE.
So it should never return SQLITE_FULL. Under a disk full condition it
should return SQLITE_ERROR, and then you would get the SQLITE_FULL error
when you called sqlite_reset (see the section Goofy Interface Alert).
Nonetheless, you are saying you are getting an SQLITE_DONE when the disk
is full.
What does the version 3.3.4 sqlite shell give you when you do an explain
on a commit statement?
sqlite3 test.db
.explain on
explain commit;
Dennis Cote
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
