You have pointers to the compiled SQL statements. You should be able to
track when the destination of those pointers changes. I haven't had the
need to do it, but it is where I would go if careful examination of the
code did not reveal the error.
JS
Eric Scouten wrote:
If it were easy to boil down to a simple code snippet, I would have
happily done so. :-) Unfortunately, the error is probably caused
somewhere inside a relatively complex home-grown wrapper for SQLite and
is not easily distilled into something I can share here.
The question really boils down to "can SQLite offer enough information
to help me diagnose the problem it's telling me I have?"
Or to put it another way, this is essentially a memory leak problem.
SQLite obviously knows that I've lost track of one or more prepared
statements that haven't run to completion, it isn't telling me *what*
statements those are. I'm wondering if there is any way of getting that
information. Armed with that knowledge, I can probably fix my code
fairly quickly.
At this point, I don't have any reason to suspect that SQLite itself is
failing.
-Eric
Robert L Cochran wrote:
You really need to post specific code snippets, you can't expect a
definitive solution including the complete diagnosis and corrected
code from an 11-word problem statement and then a 2-line guess as to
the cause. Please show your code. Others on this forum will help you.
(I lack the expertise.)
Bob Cochran
Greenbelt, Maryland, USA
Eric Scouten wrote:
I'm getting this error periodically when attempting to commit a
transaction.
What I believe is happening is that my database abstraction layer has
lost track of one or more compiled statements that it created at some
earlier time. Is there any way to find out *what* transactions are
still operating at the time this error is issued?
That would help my debugging efforts greatly.
-Eric
