My Android app works with SQLite databases. They are created in SQLite v3.6 (legacy mode) so that they are compatible with all Android devices. However, a small set of the devices running SQLite v3.7 are auto-promoting the SQLite db's to v3.7, which makes them incompatible with older devices.
Is there a way to tell devices running v3.7 not to upgrade the database?
PRAGMA legacy_file_format = 1
According to the SQLite website:
This pragma sets or queries the value of the legacy_file_format flag.
When this flag is on, new SQLite databases are created in a file
format that is readable and writable by all versions of SQLite going
back to 3.0.0. When the flag is off, new databases are created using
the latest file format which might not be readable or writable by
versions of SQLite prior to 3.3.0.
Related
Technologies used for the app: Ionic, Capacitor, Angular and SQLite
The requirement is to use a prepopulated SQLite database in the app. The methods that I found over the internet across various blogs and forums mentioned running a SQL script to initialize the DB as a pre-population step, but this brings about an unwanted overhead time to start querying the DB. As in the user needs to wait for a minute or so for the SQL Script to run completely every time, even if the app exists.
This issue became a roadblock because when the need became to port a large-sized database, it was no longer feasible to write SQL scripts as the overhead time increased drastically. Also, a bigger problem is, in Android studio, Java started throwing Heap Memory exceeded error.
A solution that I tried was to port the database directly as an asset of the app so that it can be shipped along with the app. But, while placing the database file in src/assets/, every build of the app generates www/ to create a web app that can be wrapped in a native view. The builder and compiler delete all the contents of the previous build in the www/ folder, we must understand that the capacitor looks for the database file at www/ and not in www/assets/, but we can't place the database file at www/ as it gets deleted on every build.
Link to existing issue on using the sqlite extension
maybe my experience can help you
RULES FOR DEVELOPMENT
1
database1 of bundle ( Android APK) from /assets must be static and not for update. because they can be changed when the application will be reinstalled on you version
2
you must to create new database2 - local , on the device , programmatically - to store a user's data. you can affill this database2 with data from database1
3
when you will install new version of application: database1 one may be changed, but the database2 becomes constant
the same situation is in browser: programmatically created database not disappear from session to session.
I check - it works in my application...
I have an apk for an app and is not compatible with Android 9 because it now forces WAL instead of journal mode. Is there a way to disable WAL without access to the source code of the app?
If you don't have control over the App's source, then I don't believe that you can change the mode.
Saying that, the most likely cause of the App not working is when a pre-existing database is used (copied from the assets folder).
If so, and you have access to another device where the App is working (i.e less than Android 9) and you have access to the database file (rooted devices may be needed). The there is a good chance copying that database file from the after deleting the -shm and -wal files on the Android 9 device (again it may need to have been rooted) would work (although WAL would be used), but the issue is very likely purely the copying of the pre-existing database.
I did a test using 5.0 and 10.0 devices (emulators) and this worked fine.
However, if you did have access to the code :-
You can use the SQLiteDatabase disableWriteAheadLogging method. You would execute this by overriding the onConfigure method if using a subclass of SQLiteOpenHelper.
If not using a subclass of SQLiteOpenHelper then you could set the journal mode using the journal_mode PRAGMA.
I have an Android app where I use a SQLIte DataBase. I am using the app and the DB is already big. Now I want to give this app with its DB to my coworkers. Where and How to put the DB for release? I have the DB in my phone but I need it in assets folder. I was trying but it doesn't work. I tried to copy the DB directly however I read that Android compress files in that folder. Please, any solution, thank you in advance.
http://blog.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/
Visit this link. It contains the easiest and well described answer for your question.
You can use emulator Like GenyMotion and any other emulator. Run your app on emulator then just go to Android Studio->Tools->Android Device Monitor Then select the emulator and in the file Explorer you can find your db file . and then export from the device and export to your desktop. here you can give it to any one.
You can use your own SQLite database by adding it to assets folder. The best way is to use Android SQLiteAssetHelper. Better than reinventing the wheel.
Here the excerpts from its readme:
An Android helper class to manage database creation and version
management using an application's raw asset files.
This class provides developers with a simple way to ship their Android
app with an existing SQLite database (which may be pre-populated with
data) and to manage its initial creation and any upgrades required
with subsequent version releases.
It is implemented as an extension to SQLiteOpenHelper, providing an
efficient way for ContentProvider implementations to defer opening and
upgrading the database until first use.
Rather than implementing the onCreate() and onUpgrade() methods to
execute a bunch of SQL statements, developers simply include
appropriately named file assets in their project's assets directory.
These will include the initial SQLite database file for creation and
optionally any SQL upgrade scripts.
Some of my users are reporting that they cannot correctly open sqlite databases created in Android using sqlite jdbc or other tools like sqlite browser (http://sourceforge.net/projects/sqlitebrowser/).
Here is an example database with the problem:
http://pocket-for-android.1047292.n5.nabble.com/Desktop-Version-Screenshots-Work-In-Progress-tp4383220p4456017.html
This sqlite db was created on a HTC Sensation, running Android 2.3.3 and Sense 3.0.
The exact problem is that if you look at the file in a text editor you can see a bunch of tables being created but if you try and run "select * from groups;" you will get an SQLException: file is encrypted or is not a database.
I have tried using "select sqlite_version;" to see if it is a versioning issue - the sqlite browser says 3.6.18.but different tools give me different version numbers... not sure what is going on with that.
I should also point out that my app copies the db directly from the device (/data/data/com.citc.wallet/databases/wallet.db) onto Dropbox.
Any help would be really appreciated.
The solution was that the zentus project is not working with the latest versions of SQLite.
Fortunately someone is keeping a fork maintained here: http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC
All I had to do was replace the jar with the xerial one and it all worked. Xerial sqlite jdbc is in my opinion the best way of connecting to SQLite in Java (I tried several of the libs).
I am also getting the same problem.
But once I have changed the database name it resolved.
So, just try it by creating new database
I would like to use a Windows-based SQLite Administrator to work on my SQLite database. Is the DB file (s3db) portable to mobile platforms like iOS and Android?
A SQLite database file is just that, a file so it should work on any file system/OS regardless of where it was created. The one exception to that would be something like encoding, but the beauty of SQLite is that it's actually just an abstraction on a flat file that allows you to preform most of the relational db functionality. Also, because it's a standardized format, any client should work to read it as well (assuming both the creator and the reader conform to the specification).
SQLite db files should be OS independant. Even file system independant. The files don't have encoding like UTF-8 or ISO-8859-1 (or whatever the order of the numbers is, I always forget) because they're binary.
Have you tried?
Maybe the SQLite client matters. Maybe some clients leave signatures or something? The OS shouldn't matter.
Absolutely cross platform. From the SQLite page:
Stable Cross-Platform Database File
The SQLite file format is
cross-platform. A database file
written on one machine can be copied
to and used on a different machine
with a different architecture.
Big-endian or little-endian, 32-bit or
64-bit does not matter. All machines
use the same file format. Furthermore,
the developers have pledged to keep
the file format stable and backwards
compatible, so newer versions of
SQLite can read and write older
database files. Most other SQL
database engines require you to dump
and restore the database when moving
from one platform to another and often
when upgrading to a newer version of
the software.
http://www.sqlite.org/different.html#onefile