>You'd have to read the docs of your Delphi wrapper, but if this were the >plain C interface, then, yes, you would need to free the memory.
I've tested a dozen or so, and I'm hacking my own as well. The quality of the coding varies, naturally, from the ridiculous to the sublime. In some places, the pChar call is treated to _Free, but not at other times. Often as not, the coders fail to call _Close even if an _Open fails, even though the SQLite docs are pretty specific about that. So I really don't trust the wrapper/unit code as exemplary, and they are rarely documented with anything beyond pasdoc, if that. >"If an error occurs while parsing or evaluating the SQL (but not while >executing the callback) then an appropriate error message is written >into memory obtained from malloc() and *errmsg is made to point to that >message. The calling function is responsible for freeing the memory that >holds the error message. Use sqlite3_free ><http://www.sqlite.org/capi3ref.html#sqlite3_free>() for this. If >errmsg==NULL, then no error message is ever written." I read that. Just wanted to see if I was interpreting it correctly. There appears to be some ambivalence in the _prepare method. Specifically, I'm concluding the "if it's not nil, free it" is OK. >And now a meta-comment about asking questions in a technical forum. It >is fine to ask questions, and newbies are certainly welcome, but... > >Your best bet is to check the www.sqlite.org site first, then check your >Delphi wrapper documentation, then if that doesn't anwer your questions, >you're more than welcome to ask questions here. While "Delphi wrapper documentation" is an existential possibility, in practice it's as rare as a poker-playing unicorn. >One of the first rules of asking questions in a technical forum is to >try to answer the question yourself from the docs before asking the >question. It may not save you some time, but if a forum has many >readers, the time saved collectively if you find the answer yourself is >perhaps greater than the time it takes you to find the answer yourself. >That's what documentation is for, after all. Plus you'll likely learn >something in the process which WILL save you some time later down the road. > >I would encourage you to read through the SQLite3 C reference. It >doesn't take that long, and will be a rewarding experience: > >http://www.sqlite.org/capi3ref.html Thanks, I'm doing that. Nathan
