SQLite database on SD card

Question

I'm looking to create a sqlite database on the sd card (don't want to use up the user's internal storage). I'm familiar with the OpenHelper pattern:

public DatabaseFoo(Context context) {
    OpenHelper openHelper = new OpenHelper(context);
    mDb = openHelper.getWritableDatabase();
}

private static class OpenHelper extends SQLiteOpenHelper {
    public OpenHelper(Context context) {
        super(context, DATABASE_NAME, null, DATABASE_VERSION);
    }

    ...

so if we want to create on the sd card, I think instead we have to use:

public static SQLiteDatabase openOrCreateDatabase (String path, 
      SQLiteDatabase.CursorFactory factory);

But what is the "factory" argument supposed to be, what factory should be used?

Also a bit worried about what happens if the user removes the SD card while my app is in use..

Thanks

score 11 · Answer 1 · answered Jun 14 '12 at 07:53

Do this in your SQLiteOpenHelper constructor:

DatabaseHelper(Context context) {
        super(context, context.getExternalFilesDir(null).getAbsolutePath() + "/" + DATABASE_NAME, null, DATABASE_VERSION);
    }

It will create the database in the app's folder on the sdcard: /sdcard/Android/data/[your_package_name]/files. In that way the database will be seen as part of the app by android and removed automatically if the user uninstalls the app.

I my app I have a large database and it will in most cases not fit on old phones internal memory, e.g. HTC Desire. It runs great on the sdcard, and most apps are "moved to sdcard" themselves anyway so don't worry about the database not being accessible, because the app won't be accessible it self.

Charlie Collins · Accepted Answer · 2011-01-26T16:06:47.940

I haven't tried to do what you describe there, but presumably it could be done and might work -- with a few caveats. First, the external storage (SD card) is not secure, so any other application, or the user, could read/write to it. Second, as you noted, when it's unmounted the DB goes away.

Because of these disadvantages, you would probably be better off to try to use an internal storage database (the default), that is small and possibly includes pointers to external data (like images or files) -- that themselves can be on the external storage (and that have placeholders, or other handling, when the external storage is not available).

Still, if you want to try it, you might be better off override the getDatabasePath method of Context, such as with your own Application object, and then pass that into a regular SQLiteOpenHelper. Then you wouldn't have to worry about the cursor factory (which is optional, as the source confirms -- so just pass null if instead you want to go that route).

The ` getDatabasePath` override in either Application or a custom ContextWrapper doesn't work. Reading the open helper source code, I noticed that the method is never called, and instead it calls `mContext.openOrCreateDatabase` which creates the DB in the default internal storage. So this method should be overriden as well. — Mister Smith, Dec 05 '12 at 11:45
[here](http://stackoverflow.com/questions/5332328/sqliteopenhelper-problem-with-fully-qualified-db-path-name/9168969#9168969) you can find a working example of overwritten getDatabasePath and openOrCreateDatabase that works on android 2.2. and android 4.4 — k3b, Feb 16 '15 at 14:41

score 2 · Answer 3 · edited Mar 11 '15 at 07:16

2

public DataBaseHelper(final Context context) {
    super(context, Environment.getExternalStorageDirectory()
    + File.separator+ MYDATABASE_NAME, null, MYDATABASE_VERSION);
}

Also Add permission in android Manifest

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

edited Mar 11 '15 at 07:16

Halvor Holsten Strand

19,829
17
83
99

answered Mar 11 '15 at 06:53

sarath chambayil

77
1
3
11

score 2 · Answer 4 · answered Jan 26 '11 at 15:57

2

Cursor factory is used to return an instance of your custom Cursor implementation. Generally you just use SQLiteCursor, in which case null is passed as factory argument.

answered Jan 26 '11 at 15:57

fludent

364
3
6

score 2 · Answer 5 · answered Feb 09 '11 at 16:38

Then make your own flat database - most people have very little internal memory, and its annoying that they eat it up with huge database.

And as for the 'what if they remove the SD' scenario - if the user removes the card obviously its not going to work! Clearly. Just check you didn't get an error when trying to interact with the base, and if you did, just tell you user - problem solved.

score 0 · Answer 6 · answered Jan 26 '11 at 16:03

0

I would recommend against putting a database onto an SD card - you will significantly decrease the lifespan of the card, since it has a (large, but still existent) limit on the number of writes possible and databases require quite a few writes.

answered Jan 26 '11 at 16:03

Jeff

2,835
3
41
69

1

Hi Jeff, I want to know something more about this limitation can you provide any link that better describe this issue? – Vignesh Aug 29 '11 at 10:39
@Vignest: http://superuser.com/questions/17350/whats-the-life-expectancy-of-an-sd-card - SD card write limits. That databases use a lot of writes is simply a fact of the technology. – Jeff Aug 29 '11 at 13:40
Is the number of writes realy an issue? since aug 2011 i have my old android 2.2 device with its sd-card that contains a database where there are about 6 insert-transactions every day. the sd card is still working without any problems. – k3b Feb 16 '15 at 14:37
@k3b: 6 transactions a day isn't much. For such a tiny, seldom-used database, that only amounts to 8k-30k writes. As the linked response says, SD cards are good for around 100k writes...ergo, your database may be fine, but a typical (larger, more used) database would be a poor idea. – Jeff Feb 16 '15 at 19:53
Hopefully you can use commits to batch small writes together into fewer larger ones. – rsaxvc Mar 28 '15 at 08:01

SQLite database on SD card

6 Answers6

Linked