> On Thu, Sep 19, 2013 at 4:35 PM, Richard Hipp <d...@sqlite.org> wrote: > > On Thu, Sep 19, 2013 at 5:50 PM, Igor Korot <ikoro...@gmail.com> > wrote:
> > > Now, AFAIU, I need to check if the COMMIT is successful. > > > But what should I do if it fails? Do I just report the failure to > > > the user? > > > Do I need to call ROLLBACK? And what if it will also fail? > > > And in "else" branch - do I check for "ROLLBACK" result? And if it > > > fails what do I do? > > You probably should report the COMMIT failure to the user, yes. > > Beyond that, what you do depends on what you want to do next. You can > > just call exit(1) if that is appropriate. Or you can ROLLBACK and keep > > using the connection. Or you can sqlite3_close() the database connection > > if you want. The answers to your questions are self-evident ... > OK, so if I don't call ROLLBACK what will happen? Then the transaction will continue. Any further operations will take place within the context of the existing transaction that you have not yet committed. Attempts to start a new transaction will fail. > Will I end up with the screw-up database file? That depends on your definition of "screw-up". If you mean screw-up as in render corrupt and unuseable that will depend on the nature of the error you are ignoring. If you mean "screw up" as in the database is perfectly fine but you have by your own actions rendered your own data inconsistent, that may be very likely. Especially since you want a "rule" for whether to continue or not. Whether you continue or not is your decision based upon (a) the exact error (ie, the reason why the commit did not succeed) and (b) the consequence of continuing the same transaction. It is determined by your application. > Problem is that if the COMMIT fails, ROLLBACK might fail as well. That is entirely possible. You can determine what to do by the error code returned from the commit attempt. And/or the rollback attempt. These codes will inform your decision as to how to carry on. Or to die. > That's why I ask if I have to call ROLLBACK or just continue working. That depends if given the circumstance and the failure to commit, you want to attempt to commit again, rollback, or just ignore the failure to commit and carry on depending, on if you need the transaction to commit, to rollback, or if you can just carry on. This is an application issue, not a database issue. Consider the following scenario: BEGIN; UPDATE Accounts set balance=balance-1000000.00 where acctno=394583; UPDATE Accounts set balance=balance+1000000.00 where acctno=837294; COMMIT; And the commit does not return SQLITE_OK. Is it OK to just "carry on" with the transfer not having been confirmed? Do you want to try to commit again? Do you want to rollback the transaction? I don't know. Nobody knows except the person writing the application. > Thank you. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
