> 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] -----------------------------------------------------------------------------
