> I fixed the re-open issue, but it still happens. It sounds like you haven't addressed [the key objection from Stephan][1], only the less serious secondary one, the memory leak. I'll try to put it another way: unless you move *the entire rest of your posted code* into the "if...SQLITE_OK" branch, so that the only thing the "else" branch does is print an error before the function exits, your authorizer will of course not have any effect on the code flow. However, all of that is a side issue. You speak of wishing to prevent modifications of the DB via the `sqlite3` shell as well. None of what you're chasing will prevent that. The authorizer doesn't run when it isn't compiled into every SQLite based program that could possibly open your DB, including `/usr/bin/sqlite3`. If you want to control who can access the DB, encryption is one answer. Another is putting the DB on a server that you control access to, so that you can *force* accesses to go through the authorizer. This path is basically that of a huge number of web services: I don't get to edit your Gmail archive because Google controls access to those databases through their Gmail server-side web application code. If you ship the raw DB to people, then only encryption can prevent modification. Physical access is total access. [1]: /forumpost/c9c8b52827