GOT IT!! Thanks for responding!
Its embarrassing but hopefully others can learn from my mistakes.
It turns out I was not ALWAYS calling finalize. One little "return
nil;" snuck into a case statement (see below). Bad form!
sqlite_prepare (...);
...
switch (type) {
case SQLITE_INTEGER:
Jason Jobe wrote:
I did find some where I wasn't doing that but I think I got them all.
Sometimes I use sqlite3_exec; other times, when I need to get the rows
I use sqlite3_step (with the finalize).
Then perhaps you are calling sqlite3_exec in between an sqlite3_step and
its corresponding
I did find some where I wasn't doing that but I think I got them all.
Sometimes I use sqlite3_exec; other times, when I need to get the rows
I use sqlite3_step (with the finalize).
Should I wrap either or both of these in a transaction?
I've also tried it backed by a file as well as the
On Sun, 2005-01-30 at 19:56 -0500, Jason Jobe wrote:
> Hey out there.
>
> I'm having a dickens of a time trying to debug a locking issue. I
> thought I was doing something simple enough; accessing a database from
> within one process with no threading.
>
> 2005-01-30 19:28:10.736[5716]
Hey out there.
I'm having a dickens of a time trying to debug a locking issue. I
thought I was doing something simple enough; accessing a database from
within one process with no threading.
2005-01-30 19:28:10.736[5716] sqlite:ERROR database table is locked
Trying again I get
2005-01-30
5 matches
Mail list logo