On Thu, May 8, 2014 at 11:50 AM, Simon Slavin <slav...@bigfraud.org> wrote:
> That's your job. You're the programmer. SQLite does not talk to users > and its result values should never be shown to a user. > Fair enough, but SQLite needs to give me what I need to be able to communicate something helpful to the user. A generic error code and a "Foreign key constraint failed" error message without any means of getting some context is not very helpful. > No need. You execute the command as expected. Only if it returns > SQLITE_CONSTRAINT does your software need to start doing complicated things > to figure out what caused the problem. > Yes, but what of the constraint is deferred? I get the error at COMMIT instead of when the offending DML is executed and at that point, when all I have is the error code and error message, it is impossible to find which statement has caused the violation. > I would argue that consideration of this should go into the design of > SQLite4. I don't think it's worth doing it for SQLite3. > I beg to differ. having worked with a number of databases, SQLite3 is the only one that has this defect -forgive the choice of word but I do consider it as such, and it has caused me lots of trouble from people trying to import data or trying to implement database replication, myself included. The only alternatives seem to be to execute DML statements in autocommit mode (no BEGIN/END), which as you probably guess has dismal performance, or completely refrain from using deferred constraints, which limits database design choices. If there is another solution I would be more than happy to hear it. I would be eager to switch to SQLite4 ASAP but it seems very far from even a beta release. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
