On Tue, 14 Oct 2008 22:10:12 +0700, Dan <[EMAIL PROTECTED]> wrote: >ABORT seems right to me. Causes the current statement to have no >effect, but does not rollback the current transaction.
On Tue, 14 Oct 2008 11:16:17 -0500, Stephen Woodbridge <[EMAIL PROTECTED]> wrote: >I'm not sure there is a "standard" answer. The "right" answer probably >depends on the needs of the application and whether it is robsut enough >to deal with various situations that might occur that would trigger a >conflict. > >For example: > >1) under what conditions might a conflict occur? >2) does the application code doing the insert have a recovery if it fails. >3) is the application communicating back to a real user that can decide >how to handle the situation? >4) is this an automated process that needs to work or fail leaving the >DB unchanged on failure? After considering both of your inputs, I have changed the triggers to "ABORT." I always check my returns and issue a ROLLBACK on errors, so this is really the best choice. JAB _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
