3

The stack trace is below:

   android.database.sqlite.SQLiteFullException: database or disk is full
        at android.database.sqlite.SQLiteStatement.native_executeSql(Native Method)
        at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:90)
        at android.database.sqlite.SQLiteDatabase.executeSql(SQLiteDatabase.java:1917)
        at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:1857)
        at android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:719)
        at android.database.sqlite.SQLiteStatement.releaseAndUnlock(SQLiteStatement.java:273)
        at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:96)
        at android.database.sqlite.SQLiteDatabase.delete(SQLiteDatabase.java:1759)
        at com.test.testapp.recovery(test.java:289)
        at com.test.testapp.run(test.java:167)

While the codes I have is only to delete that entry.

   mDatabase = dbOpener.getWritableDatabase();                  
   mDatabase.delete("table", "name = ?", "row1");

I thought it would only be possible for the disk to be full when inserting into the database. Any ideas?

sammiwei
  • 3,140
  • 9
  • 41
  • 53
  • Do consider the case where the disk *might* actually be full, even if is a delete, it is logged in the journal. – Machinarius Jul 19 '13 at 22:27

2 Answers2

0

Here is more information on SQLite Database structure and use that helped me. Deleting rows isn't necessarily opening space.

Edit from SQLite FAQ: I deleted a lot of data but the database file did not get any smaller. Is this a bug?

Edit #2: Use of VACCUM command to actually free space.

Essentially, space is marked as "free" but kept closed on the disk in order to reuse for new inserts. If all you are doing is deleting rows, that space is never returned to disk. You'll need to use VACCUM to return it.

Community
  • 1
  • 1
Phoenix
  • 1,881
  • 5
  • 20
  • 28
-1

The best thing you can do is confirm what database files are on the device, and how big they are. Simply connect the device and run an adb shell command like this (obviously replacing com.yourpackage with your package):

adb shell "ls -las /data/data/com.yourpackage/databases/*"

I found that my automated tests were leaving lots of database files on the file system. This included files ending with -wal, -shm and -journal.

For me the fix for -wal and -shm files was to ensure I called .close() on my database before deleting it, as that ensures the temporary files are deleted.

As for the -journal file, I added a tearDown() step to explicitly delete them.

Dan J
  • 25,433
  • 17
  • 100
  • 173