We have a Windows 8.1 universal app published on the Windows store. Due to a requirement change now we need to add some fields to an existing table. We have used SQLite for Windows Runtime (Windows 8.1) and SQLite for Windows Phone 8.1. Now if we add some new fields to an existing table (by updating the model classes) will that cause any issues when the existing users update the app?
Instead of adding new columns if we create a new table, then can that cause any issue or will that be safer than adding new fields?
Adding a new column to an existing table is perfectly safe even with an existing SQLite database. Same goes for creating a new table. The concrete process depends on which SQLite library you are using.
If you are querying the database directly using SQL queries, then you will use ALTER TABLE ... ADD COLUMN query. If you are using library like sqlite-net-pcl, you get automatic migrations out of the box when you run the CreateTable method. As documentation says:
The automatic migration, currently, only supports adding new columns. If your classes have new properties that are not associated with columns in the table, then alter table ... add column commands will be executed to bring the database up to date. These new columns will not have default values and will therefore be null.
Tip
When you change the model, always test out the changes against the previous version of the database. This can be done in two ways:
Install the existing version from Store, launch the app and use it so that it contains some data, then close it and go to C:\Users\[UserName]\AppData\Local\Packages. Here navigate to Packages and there find your app's package folder. Inside go to LocalState where you should find your sqlite database. Copy it somewhere, uninstall the Store version and launch the new version for debugging and place a breakpoint in the App.xaml.cs constructor. When the debugger stops there, copy the original database back to the same location in app package LocalState folder and continue debugging. Observe if the database is migrated properly.
Using Git source control, go in history to the previous release commit, install the app for debugging, fill the DB with some data, close the app. Now go to the latest commit and launch app for debugging again. Verify the migration works.
Related
I'm developing a windows application which uses SQL Server Database. I have different versions of this application and they have different database structure, so I need to migrate database to the latest version on application start. I want to compare the database structure with the application model, then do alter, create or drop commands.
Also I want to use EF Code-First ORM, after some search I've figured it out that there are some useful commands and configs in code first. But the problem is, as I know, all of them drop the existing database and create a new one so the data will be lost while I need the data.
I used these lines in my application start function:
var migrator = new DbMigrator(new Configuration());
migrator.Update();
But after execution this line I will get this exception:
There is already an object named 'SomeTable' in the database.
I know that, it's right and there is that table but in structure is changed! How can I compare the structure and do the rest?
That's not how migrations work. You need a migration for every version of your database so EF can check the __MigrationHistory table and see if it has been applied. If your initializer is set to MigrateDatabaseToLatestVersion your database won't be recreated on model changes.
You could try to recreate the history: roll back to your oldest database, add a migration, add 2nd oldest version changes, create a 2nd migration, etc.
Another option is to add a migration for where you are now, generate a script (update-database -Script) then comment out the stuff that exists in each deployed database before applying it.
Yet another option would be to use the VS Schema compare utility against each database and your current database to get the changes over. Then apply a baseline migration to each (add-migration Initial -IgnoreChanges).
Now moving forward you can generate a series of migrations and your code should work as expected.
I am creating an app it takes data from the server and storing it in SQLite database but each time I run the app the data gets append in the database. I tried onUpgrade() method to drop table and create a new one, but its not working because db_version is the same. But if I change the version manually then its working... but I want solution so that my version changes each time automatically when I run the app....
OR if there is an another alternative please share it....
You are probably didn't understand what is database Upgrade. In two words you upgrade the version of your database when your DB model changed, not the data!
To clear your database for testing purposes use sqlite DROP TABLE or physically delete the file!
If you upgrade the version of the database each time your app starts - you will lose all the database data each time your app starts, so why do you need the database ?
I have deployed the 1st version of my wp8 in wp store and now i want to deploy the update version of it. Though I know the process of update deployment, but my concern is the sqlite file which doesn't get updated.
Here is the scenario, I have sqlite file in the app where user can store config and setting, in new version I added extra tables and I want to these tables should be reflected in the the update without affecting user settings and config.
What points I should consider to take care of this issue?
Thanks!
Assuming the data in the sqlite database is static you can give the database a new name and submit it with the updated app. One first run copy the new database to isolated storage and delete the old version of the database to save space.
If the user is inputting data into the database you will have to include code to modify the database structure on the first run and insert any records into the new table
Sql Azure does not support changing a table key. There is a work around: create a new table, transfer the data, delete the old table.
Because of this limitation, EF (4.3) is not able to migrate my model after changing a table's key.
What can I do to get EF code first to accept the new database after applying the manual work around? (Without having to drop the entire database or touch other tables)
Thanks
With a bit of manual editing you can get everything of this done inside a code based migration.
Change the key in your model (through annotations or the fluent API).
Run add-migration from the package manager console to get a new code based migration.
Exchange the generated migration steps in the migration file with the create-transfer-delete-rename method required by Azure.
Now when you run the application, the update to change keys will be done using your custom migration steps fit for Azure, rather than the default code.
How to manage database changes while upgrading desktop applications?
We have a SQLite database for one of our desktop apps. The uninstaller keeps the database to be used by the next install. But what if the next install has an updated version? How to keep the data but upgrade the tables?
We use .NET and Linq2sql
Here is how I do this:
In my code I define the version of the database
#define DB_VERSION 2
This version number is incremented every time I make a change to the code that 'breaks' the database ( makes an incompatible change to the schema or the semantics of the db contents )
When the code creates a new database, it executes this SQL command
QueryFormat(L"PRAGMA SCHEMA_VERSION = %d;",DB_VERSION);
Note that this must be AFTER all CREATE TABLE commands have been executed, otherwise sqlite increments SCHEMA_VERSION.
When the code opens an existing database, the first thing it does is
Query(L"PRAGMA schema_version;")
The SCHEMA_VERSION that is returned from this query is compared with the DB_VERSION. If they do not match, then the database was created by a different software version. What happens next depends on the details of what you need. Typically:
database was created by a more recent software: inform user and exit
database was created by older software for which there is an upgrade: offer user option to run upgrade code, or re-initialize database
database was created by older software with no upgrade: offer user option to re-initialize database or exit.
The details of how the upgrade code works depends very much on what you need. In general open the old database AND open a new empty database. Read the old tables, convert the data as required, and write to the new database. Close the dbs. Delete the old db. Rename the new db to the standard db name. Open the new db.
If nothing else, the output of echo .dump | sqlite my_database.sqlite is designed to be extremely portable, even to non-SQLite databases.
Or, if I'm misreading your question, you may want alter table.