Jef Driesen wrote:
[EMAIL PROTECTED] wrote:
Jef Driesen wrote:
I did. sqlite3_close is called automatically for SQLITE_NOMEM, but not
for other cases. So I guess sqlite3_close is still needed. But then it
shouldn't return an error, or am I wrong?
I don't think any error other than SQLITE_NOMEM is possible for
sqlite3_open(). Are you seeing some other kind of error come up?
I get SQLITE_CANTOPEN for a non-existing file (and no write permissions
to create it). Using sqlite3_close immediately afterwards returns the
same value. And sqlite3_errcode returns SQLITE_MISUSE.
I think this indicates there is definitely something wrong here. Either
the documentation is incorrect (with regards to the usage of
sqlite3_close after a failed sqlite3_open), or there is a bug in
sqlite3_open/close.
I'm using sqlite version 3.3.5 (Ubuntu Edgy package) if that matters.
I can only think of one reason why the sqlite3* handle is not released
automatically after a failure. If the handle is freed and set to null
(like is done for sqlite3_prepare), it's not possible to retrieve more
information about the error by means of the sqlite3_errcode and
sqlite3_errmsg functions.
SQLITE_NOMEM is the exception here, because a null handle is also
treated as SQLITE_NOMEM by the error functions. Releasing the handle has
no effect on the error reporting in this particular case.
_________________________________________________________________
Did you know that Windows Live Messenger is accesible on your mobile as from
now? http://get.live.com/messenger/mobile
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
