On Wed, Oct 8, 2014 at 8:01 AM, Clemens Ladisch <clem...@ladisch.de> wrote: > Peter Haworth 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. > > SQL constraints were designed to catch _programming_ errors, not _user_ > errors.
Reference please? Anyways, that might be, but duplicating constraints checking in the calling program is rather obnoxious. After all, SQL is extremely expressive, and one of the main reasons to use it -- if you have to duplicate SQL code in the calling program because of insufficiently rich error reporting then why use SQL. Also, even if your assertion is correct, there's no reason that the RDBMS can't report check constraint failures more usefully. The point of being able to name constraints is almost certainly to enable this (which is evidence that your assertion is likely false, or if true about initial design, irrelevant now). >> 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. > > When you have interdependent constraints, such as "must be a closed > polygon" and "area must be at least 10", it might not make sense (or > even be impossible) to check all constraints. This is true, but if there's no way to order the checking of constraints then it doesn't matter for this discussion. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
