Hello Eric, I'd be inclined to throw it on the debugger and see what's going on. If it's too complicated to debug, then maybe you need to re-think the design. In my case, my code's littered with assertions and sanity checks that kick out when I attempt to do something wrong. Sometimes I'll implement the same thing two different ways, run both and check them against each other (in debug mode that is).
For example, if I attempt to open a DB with the same object when it's already open, I get an immediate assertion telling me I'm screwing up. My transactions commit automatically when they go out of scope and with assertion, if it fails to commit, the code stops in it's tracks and I can look at the call stack and parameters. I also trash values on purpose when something gets destructed so, if I attempt to use it after destruction, it croaks. I don't care how slow it runs in debug mode and all of my sanity checking is removed automatically in a release build. Just a thought. You know, debug mode logging works well too. It timing's important, I'll just log it's execution and line numbers to a disk file and trace through it when something fails. C Monday, December 12, 2005, 6:01:45 PM, you wrote: ES> If it were easy to boil down to a simple code snippet, I would have ES> happily done so. :-) Unfortunately, the error is probably caused ES> somewhere inside a relatively complex home-grown wrapper for SQLite and ES> is not easily distilled into something I can share here. ES> The question really boils down to "can SQLite offer enough information ES> to help me diagnose the problem it's telling me I have?" ES> Or to put it another way, this is essentially a memory leak problem. ES> SQLite obviously knows that I've lost track of one or more prepared ES> statements that haven't run to completion, it isn't telling me *what* ES> statements those are. I'm wondering if there is any way of getting that ES> information. Armed with that knowledge, I can probably fix my code ES> fairly quickly. ES> At this point, I don't have any reason to suspect that SQLite itself is ES> failing. ES> -Eric ES> 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 >>> >> -- Best regards, Teg mailto:[EMAIL PROTECTED]
