On 7 Oct 2014, at 10:00pm, Peter Haworth <p...@lcsql.com> wrote: > I'm a great believer in using CHECK constraints to do as much validation as > possible within the database rather than code it in my application. > > However, I think I'm right in saying that as soon as a CHECK constraint > fails, an error is returned to my application so no other CHECK constraints > are executed In a data entry type of application, this isn't ideal as > users would prefer to see all the errors they need to correct in one > message.
For most ways in which SQLite can refuse to do something, you have no way to know why it refused. The results don't include the name of a constraint which failed, or anything else of any use. You simply get a result code which tells you that the operation failed because of the data in your command (rather than because the command had bad syntax or referred to a table/index/column which didn't exist). > I can't think of a way round this but wondering if anyone has found a > technique to return all CHECK constraint errors at once. It would appear that in SQLite the CHECK constraints are useful only in ensuring your database doesn't reflect things that are impossible. It is of no use at all in knowing why a command is rejected. Ideally, if a result code indicates a constraint failure, there would be a way to retrieve a list of the names of the constraints which would have been violated. However this is not possible in SQLite3 at all without a major rewrite. SQLite3 just gets a binary indication of whether any constraints were violated. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
