Hello,
I think that SQLite reports the first constraint which fails:

http://sqlite.org/changes.html
2012-05-14 (3.7.12)
Report the name of specific CHECK constraints that fail.

sqlite> CREATE TABLE test (data TEXT CONSTRAINT notEmpty CHECK
(length(data) > 0));
sqlite> INSERT INTO test VALUES ('');
Error: CHECK constraint failed: notEmpty

Regards.

On Tue, Oct 7, 2014 at 11:11 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
> 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
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to