You should use a web API to allow a password change on the server and trigger that API from the app. That way, the user should only be able to change its password from the app and while connected to the server. But the user's password should not be used to directly encrypt the database but only to encrypt a (large and random) key. The general workflow could be:
- user asks for a password change on the app
- app asks the old and new password
- app confirms the old password with the server through a secure (SSL encrypted) connection - optional
- app asks the server to change the password by giving the old and new ones over a secure connection
- app decode the database key with the old password
- app encode the database key with the new password and saves it in permanent storage
That way the user experience is correct because he only declared his password change once and the app and the server are still in sync after that.
Unfortunately, this is only a general workflow, because even if it is immune to an early connection failure (simply keep old password if server could not change it), the worst case would be if the server could change its password but lose the connection before acknowledging it to the app. As usual, the devil is hidden in the details of worst case failure and the actual protocol should ensure that both sides returns to previous state if a problem occurs before the end.