Re: [sqlite] Using prepare, step, finalize and handling BUSY answers

2006-07-21 Thread Jay Sprenkle
> That's what I think as well. But, when you say 'all your suggestions' are you talking about sqlite3_interrupt too? That would be useful if you were doing queries where you don't know how long they will take. All my code is written in a way the queries are short so I would not have to abort lon

Re: [sqlite] Using prepare, step, finalize and handling BUSY answers

2006-07-21 Thread Daniel van Ham Colchete
Jay Sprenkle wrote: >> Jay, thank you very much man! That answers a lot. And it showed me that >> I was not checking the SQLITE_LOCKED case. >> >> But, from what I can see, if your database is busy or locked you just >> stop your program execution, or you will end this function WITHOUT >> running n

Re: [sqlite] Using prepare, step, finalize and handling BUSY answers

2006-07-21 Thread Jay Sprenkle
Jay, thank you very much man! That answers a lot. And it showed me that I was not checking the SQLITE_LOCKED case. But, from what I can see, if your database is busy or locked you just stop your program execution, or you will end this function WITHOUT running neither sqlite3_finalize nor sqlite3_

Re: [sqlite] Using prepare, step, finalize and handling BUSY answers

2006-07-21 Thread Daniel van Ham Colchete
Jay Sprenkle wrote: > Here's some example code: > > sqlite3*db; > > // connect to database > if ( sqlite3_open( "test.db", &db ) ) > throw "Can't open database"; > > char* sql; > > // two forms of the same sql > sql = "SELECT one.test1, two.test2" > " FROM one" > " INNER JOIN tw