Develop Reference

Will sqlite database with user infomations gets deleted or reset after new update of app

I have a question related to database, i know this is not a right platform related to question but i know here i can find great developer.
My query is,
"I am going to develop an app which deal with SQLite
Database and a lots of data into the App and user saves a lot data.
so, what if i release new update to play store and user update the app;
will the user get all the data from the SQLite they saved in the previous version of app 'or' the user have to save info again into the database?"

No, it won't get deleted.
Database will get deleted if it meets following scenarios :
If developer programmatically tries to clean data of the app / User clears data of the app from App info page.
if Developer upgrades Database version after update (It'll call onUpgrade() method in SQLiteOpenHelper & developer has cleared all
table content there).

It depends on the way you are using the database, but in general what you are searching for is "database migration". You can define how the database should behave on an update (database version increased). If you did not modify your database schema, then it will stay the same as before updating the app.
In case you use room: Migrating Room databases
In case you use SQLiteOpenHelper: onUpgrade

How can I handle updating the database in my application and at the same time retaining user scores and settings?

I have a phone application that uses a database of words and tests a user to see which words they know. I have a SQLite database with the words that I populate using a console application and this is then deployed as a resource to phones etc.
When the user runs the application then it stores pass fail data in the same database but in different tables.
When I update the application a fresh copy of the words database is installed on the phone and all the user data is lost.
How is this typically handled? Do phone applications that use SQLite have multiple databases with one being used to store user data and the other holding data which can be brought in when the application is first installed or updated?
If multiple databases are used then is it possible to create a look up from one database to the other?
Thanks in advance for any help, advice or links that point me in the right direction.

I would use a file (JSON, or plain text) to ship the words with the app. Then, when the app runs, it reads that file and adds the new words to the database. This won't affect the other tables.

Instead of having to deal with that, we hard code the values into a static method in code. Then at runtime, we see if there is any data in the table and, if not, we grab the hard coded data and do an insert.
In your case, I would also just add a version number of some kind so then, if the version was lower or the table was empty, you do a delete all and then insert your new static data.

Updgrading database downloading it from a server

I have an app that creates a database and do some stuff. I am wondering if i upload a new db to a server and download it to the exact folder where the older one exists it will be overwritten and i am good to go? Or there will be a problem. Assuming it has the same name, same column names, etc. Of course i am reffering to sqlite.

In Android, when performing a database update you should be using onUpgrade inside of the SQLiteOpenHelper. One way of doing this is to download text files that include the sql instructions needed to modify the current database or update rows with new data. The reason you have to do this is because Android will only create the database once. After the initial creation the call to onCreate for the database will not occur.

Strategy for updating Android app (with database)

Please forgive me if this question has been answered - I searched and couldn't find it.
I have an Android app that I want to upgrade, and it uses a SQLite Database. I want to update some of the application logic in the app, but there will be no updates to the database schema or contents. I basically need to keep the database exactly as-is for the user.
Do I need to do anything in onUpgrade to ensure that the database is kept, or can I leave the DB stuff alone for this update?

The onUpgrade() method is used incases of version change. Which means the database stored in the phone needs to be altered or dropped or deleted and a new database to be created. As your application does not have any of these requirements you can leave the DB stuff for this update.

This related article may help you with your question.
The way that I understand it, is that you need to put your database changing code in onUpdate() if you WANT to update between versions. But since you don't intend to, and are probably keeping the database version the same, then you will most likely have no issues at all.

Upgrading will NOT interfere with SQLite. Changes to db structure will not be implemented unless you programmatically do so (in onUpgrade method) or you uninstall and reinstall your app.
As long as it is the SAME application that you are upgrading, your db will not be affected and your data will not be affected either. If you change the signing key used in building your apk, your db will be recreated.
Conversely, if you change database structure at any given point, your onUpgrade method will come into play. You will be forced to backup, drop, recreate and repopulate tables which have been changed between versions (oher tables remain untouched both in structure and in data).
NOTE: In debugging, i just uninstall and reinstall the app every time i make db changes, but in production you DONT want to do that.

Android database approach for future updates

What is the best way to work with the sqlite database in android?
The sqlite database file (copy it for the first time into the application environment)
OR
Creating the tables in code (in database helper's onCreate())
My database has 6 tables and it is empty for the first time. I ask this because I want to update my database in the future and would want to know the best approach for this.
Thank you!

You should create (in code) it the first time it is used. Android offers the SQLiteOpenHelper class that should be used for it. SQLiteOpenHelper defines the following methods:
onCreate(SQLiteDatabase db): invoked when the database is created, this is where you can create tables and columns to them, create views or triggers.
onUpgrade(SQLiteDatabse db, int oldVersion, int newVersion): Invoked if the used database is older than the current version. Handle here the upgrade stuff (data migration, table creation/deletion)
See here for a good tutorial: http://www.codeproject.com/KB/android/AndroidSQLite.aspx

If you don't expect to have your db updated by user interaction, the file might be the best option, especially in the case that you have a lot of data to insert (file copying vs a bunch of inserts).
On the other hand, if you expect to have some data altered or added by the user, the file approach will work only in the first release.
Any time you will need to update your schema or add new data (releasing an upgrade), you will need to consider that the existing data might be changed or enriched by some stuff that the users will expect to find AFTER the upgrade.
So replacing the file is not an option anymore.
In case you need to use the sqllite helper approach, I'd love to hear some feedbacks on my sqllite helper code generator that you can find here: github

Not specific to SQLLite or android, however I have worked on a Windows trading application where users could save down Xml 'documents' - ie: a custom view saving their reporting preferences and various other flags which could then be shared around the team. On startup a user's profile was loaded and their documents parsed to customize the UI.
The application was to have a release every 3 weeks and existing documents needed to work with the new application. This was a problem as occasionally the XML schema changed resulting in new or deleted fields.
The solution we came up with was to create an abstract type called Patcher. Each release could have one or more DerivedPatcher types with it which were run on the first load after an update. The Patcher would have an abstract method to patch the XMl documents. Meaning an XML document would be loaded in with the old schema and upgraded, saved back in-place using the new schema. The Patcher would also have a rollback method to allow unrolling if an error occurred.
The same approach could be applied to tables in a database. Basically if you can create a patcher or PatchManager to serialize key tables to XML in memory, then apply the DB changes and write the data back, you can achieve database migration in a generic, re-usable way.
A key benefit of this method is it can be tested on developer PCs before deployment, so long as you have access to some sample SQLLite data. Knowing how your users use your application is key here.

For large amounts of data you might want to consider this kind of solution: Create an empty database in code and provide an activity which responds to an intent with this action: android.intent.action.SEND. Respond by parsing the sent file and populate the database with the contents. Design a format which can be easily parsed (XML is not needed for everything ;-) so the code to parse the file and fill the database is small (my binary for this including an UI to show progress (which is the larger part of the activity) is less than 12 kB in size).
The file may be distributed separately (extra apk, download, whatever). The benefit of this approach is that you do not need to store your initial database content within the apk and thus the data is only stored once on the device (after the file has been deleted). Otherwise you have the data in the database plus the source code or asset in the apk.