>>Does this >> >>var >> pMsg: PChar; >> >>.. >> pMsg := SQLite3_ErrMsg(aDB); >> >>necessitate this? >> >> if pMsg <> nil then SQLite3_Free(pMsg); > > >It depends. If you use sqlite3_exec, then yes, if you use the other >method (sqlite_prepare) then I would say no, depending on your >definition of the word "ephemeral" ;-)
Not sure I like the sound of this. Heh. I'd like to write a generalized message handler (I'm not calling it an error message handler because "OK" is not an error... well, not usually.) >>From the docs: > >sqlite3_exec method: > 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() for this. If >errmsg==NULL, then no error message is ever written. So my if pMsg <> nil then SQLite3_Free(pMsg); would cover that, wouldn't it? >sqlite3_prepare method >The sqlite3_errcode() routine returns a result code for the most >recent major API call. sqlite3_errmsg() returns an English-language >text error message for the most recent error. The error message is >represented in UTF-8 and will be ephemeral - it could disappear on the >next call to any SQLite API function. sqlite3_errmsg16() works like >sqlite3_errmsg() except that it returns the error message represented >as UTF-16 in host native byte order. My understanding of how the _prepare method works is limited--I'll follow up on that in another post. But from this my interpretation suggests that if pMsg <> nil then SQLite3_Free(pMsg); would still be a safe line to write, but the pMsg /content/ would not be a reliable indicator of the /present/ state of the SQL being processed, only of the last error. This also seems to imply that the code can continue to run even after an error, which is not the behavior I'm looking for. More on that in my next post. Thanks Nathan
