How do I apply EF7 migrations on an Azure database?
According to this link, you simply tick a box in the Publish Profile settings. Well, I don't have that checkbox - I'm not sure if the profile configuration has changed since then but I don't even have a databases section.
According to this link, EF7 doesn't support database initializers and you have to use nuget package manager or k (dnx) migrations. I'm not sure about the nuget option, so going with the dnx option: how do I connect to my Azure (hosted) project/website using a dnx console window or the Package Manager Console in VS?
Are there any other options (hopefully easier!) for doing this?
Here's the 'new' way:
_context.Database.EnsureCreated();
_context.Database.Migrate();
Simple.
My Azure database somehow had some migrations applied, but nothing in the __EFMigrationsHistory table, so I dropped all other tables and then ran all the migrations to get it back to where I wanted it.
I've managed to apply the migrations by changing my connection string on my local project, opening the firewall on Azure to my IP address, and running a dnx . ef migration apply command.
However, that doesn't seem like a good solution to me: now I have to store my live connection string in my dev project and keep switching between the two. There must be a better way...?
Related
Is it possible lock the database from any other connections when running the migrations through Database.Migrate()?
We have multiple service instances running the same code (on AWS Lambda), and do the migrations on startup. Now we have to manually make sure that only one instance is running when we want to apply some migrations, otherwise they can both try to do it and break things bad.
Is there a database level solution to this?
ef-core 2.1
Not really sure if this is what you are looking for, but if you are willing to add plain SQL to your migration you could set database to single user mode: Read more
I have recently upgraded Asp.Net Identity V1.0 to V2.0. Because of this, in Identity database few more columns get added like Email, IsEmailConfirmed etc. without any data loss.
I like to know is there any way to downgrade from Asp.Net Identity V2.0 to V1.0 without any data loss.
I have tired many ways but I am not able to retrieve Identity V1.0 database without data loss. Have spend nearly 3 days in search of good tutorial/blog for downgrading activity but not able to find one.
Any help much appreciated.
No source control or backups I assume?
One thing you could possibly do is use code first migrations:
1) Open an Identity Version 1 of your solution. If you can't find one, just do a new project with Identity Version 1.
2) From the console, enable-migrations then add-migration -IgnoreChanges initialIdentity1 followed by update-database. This will create a migration with a snapshot of the current database state.
3) Upgrade to Identity 2.
4) From the console, add-migration identity2update followed by update-database. This will create a migration with the differences including a method called Down() that will contain the information needed to move backwards.
5) Generate a script that can be used to move backwards:
update-database -Script -TargetMigration initialIdentity1
6) Apply that script to your database and downgrade the Nuget Identity package.
Now make a backup and add your code to source control :)
I am building an ASP.NET MVC EF app with code-first migrations and hosting it in Azure with Azure SQL DB. The first time I published this, it went fine. But since then my models changed, and my schema in the Azure DB is not getting updated to match. When I deploy, I do have "Execute Code First Migrations" checked. When that wouldn't work, I deleted my DB and then recreated it in the Azure portal, figuring that would trigger it getting updated. But then that didn't work, so I set AutomaticMigrationsEnabled = True in the migration Configuration. It is STILL not working, so currently my DB in Azure has none of my tables. HOW can I get the DB in Azure to be forced to update to match my models so the published site will work?? I did try looking for if there's a way to script the VS local DB to a Create query and execute that in SQL management studio, but couldn't find how to do that.
If you have made sure that you have selected update database in the publish setting, and the connection string is correctc and its still not updating. Maybe the following will help for you:
I sometimes get an issue like this, it is quite frustrating, My publish file is correct and my settings are set to allow SQL updates to occur during publishing. But sometimes the database hasn't been updated and I get a nice "backing context has changed" error, sometimes the culprit is the migration table that hasn't been updated. Unfortunately the only sure way to get your databases in sync is to check what migration history they are both at, by comparing [dbo].[__MigrationHistory]
If your published server is missing the latest migration history, then you can generate an SQL script of that by typing into the package manager console:
Update-Database -Script -TargetMigration [migration name]
'migration name' should be the name of the last migration that your published server had, visual studio will generate sql script that can be used to bring the database up to the latest migration from that target migration.
Sometimes (though very rarely, its only happened once or twice for me) the above doesn't work for whatever reason (usually because migration files have been deleted), if that is the case then its a good idea to script the whole database, and cherry pick the sql you need from that.
Update-Database -Script -SourceMigration:0
This will generate a script for every migration, you can then cherry pick based on the changes you've made. The 'latest' changes will be closer to the bottom of the file. every migrational change will start with an if check:
IF #CurrentMigration < '201710160826338_mymigration'
BEGIN
You can use this to pick the bits that you need, if you do pick the SQL be sure to include the update to the migration history. It will be at the end of the if block and look something like this:
INSERT [dbo].[__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion])
VALUES (N'201710101645265_test', N'API.Core.Configuration', 'Some long checksum')
Including the migration history will ensure that visual studio doesn't have the problem again.
Hope this helps.
very new to flyway and have added it to my project using flyway-maven-plugin.
using oracle 11g db.
Looks to be great for database versioning in a development environment but can anyone tell me:
how to use to produce database create/upgrade artifacts that i can send to a customer.
we have packages, data, ddls etc (that would be nice inside an installer)
Thanks in advance.
You can always bundle the migrations directly with the Flyway Command-line tool and send that.
I need some clarification on when to register a Database as a Data Tier Application (DAC). I've looked at all the guides but am stuck on a few points.
The database is NOT registered
Build Database Project to produce DacPac
Publish the Database Project
Check "Register as a Data Tier Application"
Check "Block publish when database has drifted from registered version"
First time round, this works. It registers the database and succeeds.
However, on subsequent publishes is fails as it says the DB has drifted noting two users which have not changed.
Am I following the correct process? i.e. setting the Publish script to re-register each time?
What is the best practice for making changes? By changing the relevant .sql files in the Database Project and then building? The guides talk a lot about being able to version the DB using the DacPac but its not clear how. Should I rename each DacPac and commit it to TFS?
My next step is to publish the Database as part of the overall ASP.Net Solution. When I try to do that (it works fine when the DB publish is not included), it comes up with the following error
Web deployment task failed. (The SQL provider cannot run with dacpac option because of a missing dependency. Please make sure that DacFx is installed. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DACFX_NEEDED_FOR_SQL_PROVIDER.)
However, I have all the required elements installed on the publishing machine. Do they need to be on the SQL Server or IIS VMs?
Any guidance would be much appreciated.
If you want to deploy your changes to a database using a dacpac you would need to register the database as a DAC. This basically creates a snapshot of the database at that point in time. You do this before making a change to create the initial snapshot and then after a deployment.
The reason you do this is to detect drift. Lets say you do a deployment and someone makes a change directly in that database, for instance changing the logic of a stored procedure, you would want to know about that change before making a subsequent deployment. If you deploy your dacpac and ignore this change it will revert their change to whats in the dacpac model. This is where drift occurs. You can generate an xml report on what has drifted through the sdk.
You can enable a setting to disable deployment if drift occurs so that you can retrofit those changes in the database directly in your source code. You would then need to re-register the database as a DAC to create a new snapshot.
Am I following the correct process? i.e. setting the Publish script to re-register each time? Yes
What is the best practice for making changes? By changing the relevant .sql files in the Database Project and then building? Yes
The guides talk a lot about being able to version the DB using the DacPac but its not clear how. Should I rename each DacPac and commit it to TFS? You can set a version within the databse. Have a look at the properties of the database project. You shouldnt rename the dacpac.
About the ASP.Net publish, I would need a bit more detail around the project structure and environment setup.