On Thu, Oct 13, 2011 at 07:52:59PM -0700, fe...@crowfix.com scratched on the wall: > On Fri, Oct 14, 2011 at 02:17:20AM +0700, Dan Kennedy wrote: > > On 10/14/2011 01:29 AM, fe...@crowfix.com wrote: > > > I'm working on a project which generates tables from a config file, > > > and it seems to be happy on a Mac OSX running 3.4.0, but Linux running > > > 3.7.8 complains about an insert with the unhelpful message > > > > > > (foreign key mismatch)
> It works on MacOSX with sqlite 3.4.0, and the exact same code fails > under Linux with sqlite 3.7.8, It does *not* "work" under 3.4.0, as that version of SQLite does not have support for foreign keys... The issue, be it a bad foreign key statement or bad data, is still there. That version of SQLite is simply too old to even know what a foreign key is, never mind when one might be wrong. > but if I use sqlite to repeat the same failing SQL statement, > it works fine under Linux. For the likely reason Dan gave: the command line does not have foreign key checks enabled by default. Unless you explicitly turned foreign key support on in the command line tool before repeating the relevant statements, your command-line test proves nothing... it did not "work fine" under Linux. The error condition was not reported because the error condition was never checked-- not because there were no errors. > But I repeat myself. And we heard you. And responded. Try listening. > > > I've checked all the data and don't see what it is complaining about, > > > and if I dump the SQL to a file and execute the same commands that > > > way, it works, and so does adding the single record in question using > > > sqlite3. > > > > Error message only shows up if foreign keys are enabled ("PRAGMA > > foreign_keys = ON"). They are disabled by default. > > Sorry to be grumpy, but what does this have to do with the price of > red grapefruit on Mars Colony Three? If keys are disabled, your tests are invalid. > If I get the error message, > by your own statement that must mean the pragma enabled foreign keys. And, as Dan points out, *not* getting an error message does NOT mean the error is not there-- it can also mean the error test was disabled. As it is, by default. Hence there is a very good chance your "tests" using the command line tool are meaningless. > What I want to know is if there is any way to get more better > reporting, such as the column or constraint it is upset about. No. As several have said. > The message is not helpful. I have checked all the columns, all the > values, and they are set up properly. And, as Dan was trying to point out, if those "test" included stuff like using the command line tool, the tests were likely invalid. All indicators still point to your database having a foreign key issue. > If there is no such more better > reporting, ok, I will take other approaches. If you don't know the > answer, you could either say so or say something useful or say nothing. You might want to check into who Dan is before making such statements. As with your foreign key tests, just because you don't see the value of the statement doesn't mean there is no value there. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users