One thing to note is that the SQLite.NET wrapper by default issues all transactions as "BEGIN IMMEDIATE" so if you're running the SELECT within a transaction it will be within the context of an exclusive transaction (that's what BEGIN IMMEDIATE means, right?).
You can override this by using the wrapper-specific BeginTransaction(deferred) override but it is not accessible if using the DbFactory standard interface. I completely agree with Dan that there is no way the wrapper is generating this error message, however behavior in the wrapper such as the above could be contributing to it. HTH, Sam ------------------------------------------- We're Hiring! Seeking a passionate developer to join our team building products. Position is in the Washington D.C. metro area. If interested contact [EMAIL PROTECTED] -----Original Message----- From: Dan Kennedy [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 1:25 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Still getting "Insertion failed because database isfull." errors > At first I thought this had solved the problem, because all in house testing > runs beautifully. However, as soon as the device is sent to the field, the > error starts again. Unfortunately, it means that I have never been able to > catch this in debug. I did, however, change the error reporting a little > and got some more information. The SQLiteException I am not getting > includes this information: > > Insertion failed because the database is full That message is from the wrapper. > database or disk is full And the above is from sqlite3. The corresponding return code is SQLITE_FULL. Search source file "os_win.c" for where SQLITE_FULL errors can be generated - there's only a couple of places. Odds on it's one of them. Looks like on windows, any error writing or seeking a file is reported as SQLITE_FULL. > at System.Data.SQLite.SQLite3.Reset() > at System.Data.SQLite.SQLite3.Step() > at System.Data.SQLite.SQLiteDataReader.NextResult() > at System.Data.SQLite.SQLiteDataReader.ctor() > at System.Data.SQLite.SQLiteCommand.ExecuteReader() > at System.Data.SQLite.SQLiteCommand.ExecuteDbDataReader() > at ... etc etc So is this really a SELECT? Probably good to check that. If it is a SELECT, why would it be filling up the database? Is it rolling back a journal file and running out of space like that? Or the user rolling back the journal file doesn't have permission to write the database file and SQLite is reporting the error incorrectly. Check for a journal file on the device after the error. Also run the SQLite integrity-check on the database. Dan. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
