In Azure DevOps I have a build task with the following command:
dotnet ef migrations script --output path/migrations-script.sql --idempotent
In my release pipeline I run the generated script.
The issue I've got is that the above command runs from the first migration. I know I can specify a from argument for this command, but you have to specify the name of migration. Is there any way to generate the script from the last migration without specifying its name?
Is there any way to generate the script from the last migration
without specifying its name?
As I know, it's necessary for us to specify the name when we try to generate script from last migration, unless we have only one migration.
See the details about dotnet ef migrations script:
Arguments:
From: The starting migration. Migrations may be identified by name or by ID. The number 0 is a special case that means before the first migration. Defaults to 0.
To: The ending migration. Defaults to the last migration.
So if we have more than one migrations, we have to specify From with the start migration we want. This behavior is by design. Check this post, to generate script from last migration we should use format like:
dotnet ef migrations script -from (MigrationYouWant-1) -to MigrationYouWant
So I'm afraid there's no other way to do this in Devops pipeline or local machine, we have to specify the command with name. Hope my answer can help to clarify something for you:)
Related
In Entity Framework 6, I need to get the SQL script for specific migration file and I already updated the database. I found that in update-database command I can add script parameter to export the migration to SQL, but I already updated the database. I found in Entity Framework Core, a command called Script-Migration with script name as an argument. Is there any similar command in Entity framework?
I also tried the suggestion "Update database command", but I got an empty SQL file.
Yes, you could generate the migration-SQL as follows:
Update-Database -Script -SourceMigration: <pointFromWichYouWantToStartWithGeneration> -TargetMigration: <pointWhereToEndWithGeneration>
To create a script for all migrations execute the following:
Update-Database -Script -SourceMigration: $InitialDatabase
Instead of applying the changes to database it will generate a SQL script file. Therefore you could generate a SQL Script even if the migration was already applied to the database.
Here you could find some more information about it - Entity Framework Code First Migrations - Getting a SQL Script.
Run the Update-Database command but this time specify the –Script flag so that changes are written to a script rather than applied. We’ll also specify a source and target migration to generate the script for.
If you're now in .net core, use
Script-Migration -From <PreviousMigration> -To <LastMigration>
If you don't execute the last migration, you can run
Script-Migration -From <PreviousMigration>
Don't include the date/times preceeding the migration name.
For example if the migration name in the database is: 20210209184835_add-parent-id-to-contract, then run the following in the package manager
Script-Migration -From add-parent-id-to-contract
If you want to generate -Script for migration N, you specify -SourceMigration N-1 (previous migration) and -TargetMigration N
You can run the following command from Package manager console. It will generate a temporary file and will open it in VS:
Script-Migration
SSAS 2012 and Powershell 5.0> I have a deployment automation process that runs the Deployment.exe wizard in silent mode to create an XMLA file and then uses Invoke-ASCmd to deploy the SSAS project to an SSAS server. It works fine for our proof-of-concept Tabular model, but fails on the Dimensional Cube that runs against AdventureWorks-DW. The project builds fine in VS2012 and runs locally.
I get this error out of ASCmd:
The name in the end tag of the element must match the element type in the start tag.
Followed by a bunch of these
Query (1, 1) Parser: The syntax for '<' is incorrect.
I suspect this is related to the old error in ASCmd involving RegEx and parsing the XML looking for Go commands (here), but I can't prove it. I do know the model has two Translations specified for the cube but try as I might I can't permanently delete them. I'm not sure if they're related but it's a thought.
Anyone run into this problem?
Deployment command:
Microsoft.AnalysisServices.Deployment.exe "AHP_AdventureWorksDW2012.asdatabase" /o:"AHP_AdventureWorksDW2012.xmla" /s:log.txt /d
Powershell ASCmd:
Invoke-ASCmd -InputFile D:\a5\AHP_AdventureWorksDW2012_Dim\MS_Deploy_SQL_SSAS_Dim_2_1\trunk_Showcase_AHP_AdventureWorksDW2012\AHP_AdventureWorksDW2012.xmla -Server AD1HFDASST9C1\MSBI
Well, we run into this problem when generated with Deployment utility files exceeded some size limit; the error reported by ASCMD was exactly the same. Fix - switch to cube deployment with Deployment utility itself with command like:
Microsoft.AnalysisServices.Deployment.exe <cube.asdatabase> /s
This is generating diff and deploying it on the fly.
I have a production and a development database. Now I want to generate a sql script based on a specific migration. When I enter the line to generate the script I get this error:
'201608121243147_AutomaticMigration' is not a valid migration. Explicit migrations must be used for both source and target when scripting the upgrade between them.
The command I use is as follows:
Update-Database -Script -SourceMigration:201608121243147_AutomaticMigration -TargetMigration:201608281101542_AutomaticMigration
When I execute the command get-migrations I can see those two migrations are in the list. The target migration is also my latest migration, but when I omit this parameter I get the same exception.
What am i doing wrong? What do I have to do to fix this?
Try removing the semicolon after SourceMigration and after TargetMigration:
Update-Database -Script -SourceMigration 201608121243147_AutomaticMigration -TargetMigration 201608281101542_AutomaticMigration
This works for me.
Update-DataBase -Script -SourceMigration:"Version1" -TargetMIgration:"Version2"
Regards
Abdul
I have added EF 5 to my project via Nuget and enabled migrations with the "Enable-Migrations" command. I have then called "Add-Migration" to generate the base code for generating the schema.
I then added a property to one of my domain objects (string property called "TestProperty") and added a mapping to my EntityTypeConfiguration file (we're ignoring the conventions at the moment).
Calling "Add-Migration" again produces the error:
Unable to generate an explicit migration because the following explicit migrations are pending: [201303262144218_Initial]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
But calling "Update-Database" produces a sql exception because the tables already exist:
There is already an object named 'Customer' in the database
In my constructor for my DbContext I have tried the different update strategies, e.g.:
Database.SetInitializer<UnitOfWork>(new DropCreateDatabaseAlways<UnitOfWork>());
Am I missing something obvious?
I tried the solution here but it didn't work: Automatic Migrations for ASP.NET
Thanks
EDIT: Update
The key to getting past the first step is to create the initial migration and then delete the generated code from the Up and Down methods (http://thedatafarm.com/blog/data-access/using-ef-migrations-with-an-existing-database/).
I can then update the model and the EF map and then run Add-Migration. This generates a migration with the correct Up and Down code.
The problem is then trying to apply the update. Update-Database produces the error "Unable to update database to match the current model because there are pending changes and automatic migration is disabled...automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.
You can use the Add-Migration command to write the pending model changes to a code-based migration". Ok, so I try Add-Migration again and it produces another migration with the exact same code as the last one.
I run Update-Database and get the same error again. I try "Update-Database -TargetMigration 201304080859556_MyMigration -Force" but this produces "The specified target migration '201304080859556_MyMigration' does not exist. Ensure that target migration refers to an existing migration id" - It does!
Very frustrating!
I had the same problem enabling EF migrations for a code-first model with an existing database, and the following procedure worked:
Remove the existing Migrations folder in your project, and DROP the table __MigrationHistory from the existing database.
Run the enable-migrations command from the Package Manager Console.
Run the add-migration command to create an initial migration.
Remove all of the code in Up() method for the initial migration.
Run the update-database command to apply the initial migration to your database.
This doesn't make any changes to existing objects (because the Up() method contains no code), but it marks the existing database as having been migrated to the initial state.
Make changes to your code-first model.
Run the add-migration command to create a new migration.
The code in the Up() method of the new migration will contain only the changes to your object model.
Run the update-database command to apply the changes to your database.
I run Update-Database and get the same error again. I try "Update-Database -TargetMigration 201304080859556_MyMigration -Force" but this produces "The specified target migration '201304080859556_MyMigration' does not exist. Ensure that target migration refers to an existing migration id" - It does!
There is one more issue which may cause your last error (and maybe it's a root cause of previous ones). I had a similar problem and it turned out that for some strange reason some of my migration classes where in a different namespace than the namespace of my MigrationConfiguration class. Correcting namespaces (also in xxx.Designer.cs files) solved this issue (migrations were visible and working again).
Did you try using the -force parameter to apply the changes.
Update-Database [-SourceMigration <String>]
[-TargetMigration <String>] [-Script] [-Force] [-ProjectName <String>]
[-StartUpProjectName <String>] [-ConfigurationTypeName <String>]
[-ConnectionStringName <String>] [<CommonParameters>]
-FORCE
Specifies that data loss is acceptable during automatic migration of the
database.
You can use get-help Update-Database -examples to see usage examples.
Further read: EF Code First Migrations
You do not need to remove the migration manually, remove it conveniently with
Remove-Migration
then you can recreate the migration script again with Add-Migration.
In your case, updating the database failed because there are existing tables, drop them with
Drop-Database
Then you can Update-Database.
More detailed usage of these commands are here.
Trying to migrate an old db version to a new model, either the database didn't match the new model or i got errors like :
Type is not resolved for member 'Npgsql.PostgresException,Npgsql,
Version=3.2.2.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7'
Here's how it worked (using automatic migration) :
Delete Migrations folder
Execute enable-migrations
Set this two properties to true in the newly created Configuration.cs
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
}
Execute Update-Database -Force
Your database will be updated to latest scheme and ready.
hope this helps.
This is a blanket approach that usually works:
Delete your entire Migrations folder (make sure that you copy any code that you might have created from the seed method in your migration configuration file).
Delete the actual database. If you are using LocalDb, this will normally sit within your AppData solution folder (Right-click -> open folder location). Make sure to delete the .mdf & .log database files.
Go to Package Manager Console. Enter enable-migrations -projectname yourprojectname
Go to Package Manager Console. Enter add-migration "Initial" -projectname yourprojectname.
Open the migration configuration file and paste the code that you copied from step 1 into the seed method.
Go to Package Manager Console. Enter update-database -projectname yourprojectname
This should do the trick.
1) Remove the existing Migrations folder in your project, and delete existing migration from Migration_History table if any.
2)Run the following command from the package manager console:
add-migration reset
3)After that run the following command from the package manager console:
Remove-Migration
4)After that run the following command from the package manager console (InitialMigration is the name of the first migration, you can name as you want ):
add-migration InitialMigration
This looks like a really common task, but I can't find an easy way to do it.
I want to undo the last applied migration. I would have expected a simple command, like
PM> Update-Database -TargetMigration:"-1"
Instead, all I can come up with is:
PM> Get-Migrations
Retrieving migrations that have been applied to the target database.
201208012131302_Add-SystemCategory
201207311827468_CategoryIdIsLong
201207232247409_AutomaticMigration
201207211340509_AutomaticMigration
201207200025294_InitialCreate
PM> Update-Database -TargetMigration:"CategoryIdIsLong"
(At least I can use just the name, skipping the timestamp...)
Is there an easier way?
I want to add some clarification to this thread:
Update-Database -TargetMigration:"name_of_migration"
What you are doing above is saying that you want to rollback all migrations UNTIL you're left with the migration specified. Thus, if you use GET-MIGRATIONS and you find that you have A, B, C, D, and E, then using this command will rollback E and D to get you to C:
Update-Database -TargetMigration:"C"
Also, unless anyone can comment to the contrary, I noticed that you can use an ordinal value and the short -Target switch (thus, -Target is the same as -TargetMigration). If you want to rollback all migrations and start over, you can use:
Update-Database -Target:0
0, above, would rollback even the FIRST migration (this is a destructive command--be sure you know what you're doing before you use it!)--something you cannot do if you use the syntax above that requires the name of the target migration (the name of the 0th migration doesn't exist before a migration is applied!). So in that case, you have to use the 0 (ordinal) value. Likewise, if you have applied migrations A, B, C, D, and E (in that order), then the ordinal 1 should refer to A, ordinal 2 should refer to B, and so on. So to rollback to B you could use either:
Update-Database -TargetMigration:"B"
or
Update-Database -TargetMigration:2
Edit October 2019:
According to this related answer on a similar question, correct command is -Target for EF Core 1.1 while it is -Migration for EF Core 2.0.
As of EF 5.0, the approach you describe is the preferred way. So
PM> Update-Database -TargetMigration:"NameOfSecondToLastMigration"
or using your example migrations
PM> Update-Database -TargetMigration:"CategoryIdIsLong"
One solution would be to create a wrapper PS script that automates the steps above. Additionally, feel free to create a feature request for this, or better yet, take a shot at implementing it! https://github.com/dotnet/ef6
In EntityFrameworkCore:
Update-Database 20161012160749_AddedOrderToCourse
where 20161012160749_AddedOrderToCourse is a name of migration you want to rollback to.
I realised there aren't any good solutions utilizing the CLI dotnet command so here's one:
dotnet ef migrations list
dotnet ef database update NameOfYourMigration
In the place of NameOfYourMigration enter the name of the migration you want to revert to.
Then you can remove all the reverted migrations for good using
dotnet ef migrations remove
The solution is:
Update-Database –TargetMigration 201609261919239_yourLastMigrationSucess
EF CORE
PM> Update-Database yourMigrationName
(reverts the migration)
PM> Update-Database
worked for me
in this case the original question
(yourMigrationName = CategoryIdIsLong)
In EF Core you can enter the command Remove-Migration in the package manager console after you've added your erroneous migration.
The console suggests you do so if your migration could involve a loss of data:
An operation was scaffolded that may result in the loss of data.
Please review the migration for accuracy. To undo this action, use
Remove-Migration.
Additional reminder:
If you have multiple configuration type, you need to specify the [ConfigurationName]
Update-Database -Configurationtypename [ConfigurationName] -TargetMigration [MigrationName]
I run mine through my (BASH GIT) console also running Entity Framework Core. Update-Database commands will not work outside of the package console and I have to use the donet ef commands.
donet ef database update [Name of previous Migration]
This will run the protected override void Down(MigrationBuilder migrationBuilder) method of your current migration and all of the others to get back to the version of the DB you set it to.
I also use the -p [migration project] -s [Project Solution]. This also allows it to point to my appsettings.[Enviorment].json where my password to access DB is stored.
export ASPNETCORE_ENVIRONMENT=[ENVIORMENT]; donet ef database update [Name of previous Migration] -p [Migration Project Name] -s [Solution Name]
A lot of this might be known but wanted to give detail in case your first time doing.
update-database 0
Warning: This will roll back ALL migrations in EFCore! Please use with care :)
EF CORE
Update database to the previous point
update-database CategoryIdIsLong
And then, remove the bad migration
remove-migration
I'm using EntityFrameworkCore and I use the answer by #MaciejLisCK. If you have multiple DB contexts you will also need to specify the context by adding the context parameter e.g. :
Update-Database 201207211340509_MyMigration -context myDBcontext
(where 201207211340509_MyMigration is the migration you want to roll back to, and myDBcontext is the name of your DB context)
Update-Database –TargetMigration:"Your migration name"
For this problem I suggest this link:
https://elegantcode.com/2012/04/12/entity-framework-migrations-tips/
I found that this works when run in the Package Manager Console:
dotnet ef migrations list | select -Last 2 | select -First 1 | ForEach-Object { Update-Database -Migration $_ }
You could create a script that makes it easier.
In case there is a possibility for dataloss EF does not complete the update-database command since AutomaticMigrationDataLossAllowed = false by default, and roolbacks the action unless you run it with the -force parameter.
Update-Database –TargetMigration:"Your migration name" -force
or
Update-Database –TargetMigration:Your_Migration_Index -force