I created and ran codefirst application. It created DB in files in Users/UserName
folder and added data into it. I could even pull it out. Then I manually deleted these files. I expected that if I
delete files than entity framework would create a new ones. But it throw
exception with the message: {"Cannot open database \"CodeFirstTest.Program+CarRegisterContext\" requested by the login. The login failed.\r\nLogin failed for user 'NAZAR\Nazar'."}
I didn't change nothing in properties. There isn't connection string even. All are default that entity framework nuget set.
After restarting VS I found the server where the database was created. Before restarting it wasn't appeared in SQL Server Object Explorer. Then I deleted the database fron it and now all works fine.
Related
I have been having trouble working with migrations and an Azure Sql Database for the past couple of weeks.
I run enable-migrations and a migrations folder with a congfiguration file is created.
I then run Add-Migration InitialCreate and a migration is created with empty Up() and Down() methods.
PM> Enable-Migrations
Checking if the context targets an existing database...
Code First Migrations enabled for project MyService.
PM> Add-Migration InitialCreate
Scaffolding migration 'InitialCreate'.
The Designer Code for this migration file includes a snapshot of your
current Code First model. This snapshot is used to calculate the changes to
your model when you scaffold the next migration. If you make additional
changes to your model that you want to include in this migration, then you
can re-scaffold it by running 'Add-Migration InitialCreate' again.
I deleted an old database from my App Service and created a new one. This is now being targeted in my Web.config:
<add name="MS_TableConnectionString" connectionString="Data Source=(localdb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-MyService-20180212689875.mdf;Initial Catalog=aspnet-MyService-20180212578997;Integrated Security=True;MultipleActiveResultSets=True"
providerName="System.Data.SqlClient" />
I have a feeling my code is targeting the old database which has been deleted on azure but holds the tables for the objects I'm now trying to add.
Update:
Removed the data objects and created a migration and it has been populated with the Delete code for non-existent tables(which existed in my last database). Definitely an issue with pointing to the right place. Any ideas?
Pretty new to Azure so not sure where to look to try and fix this.
Any help appreciated!
After adding migration, remember to enter "update-database" in Package Manager Console, which command runs the Up method to create the database and then it runs the Seed method to populate the database.
I have a feeling my code is targeting the old database which has been deleted on azure but holds the tables for the objects I'm now trying to add.
According to the code you provided, you set the database in Local in web.config and delete the database on Azure, but you could populate data to the deleted database on azure. There is no possible to achieve it.
Actually, when you publish you Web App to Azure, you could pick on the "Excute Code First Migrations" in Visual Studio and check if the TestContext is the database connection that you use now.
Each time you get both of them and after migrations, you will populate the data to the latest the database on Azure. You could read this article to know the details about Code First Migrations and Deployment.
I'm using EF 6.1.2. I have an existing database, and I've Enabled Migrations. When I enter the command AddMigration InitialCreate in the console, the migration that is created is empty. From what I can find researching, that's what should happen if I add the parameter -IgnoreChanges, but I'm not doing that.
Most of the Migrations documentation references EF 4.3. I haven't found anything that says it has changed for 6.1.2. Is there a new command parameter to force the migration to contain the create code? Or is something else missing in my configuration?
Thanks
My application is n-tiered with both a Web API and an MVC project. Because I have multiple start-up projects set, EF was not able to determine which application to use to find the start up configuration. I was applying the Add-Migrations to the Data Access layer but the connection string and entity framework initialization settings were in the MVC web.config. After I copied these to the App.Config of the data access layer, all worked as expected.
Before anyone marks this as a duplicate, none of the questions similar to this addressed any of my concerns or answered any of my questions.
I am currently developing all the POCOs and data contexts in a library project, and running migrations from within this project. The database I'm updating is the development database.
What do I do if I want to create the current schema to a fresh, new database? I figure that all I have to do is to change the connection string in web.config and run Update-Database, correct?
While the live/production database is up and running, I want to add new columns and new tables to the schema, and test it out in development. So I switch back the connection string to the development database's connection string, and run Update-Database.
Going back and forth between two databases seems like I'll get conflicts between _MigrationHistory tables and the auto-generated migration scripts.
Is it safe to manually delete the _MigrationHistory tables in both databases, and/or delete the migration files in /Migrations (so I'll run Add-Migration again)? How do we manage this?
What do I do if I want to create the current schema to a fresh, new database?
- Yes, to create fresh database to the current migration level you simply modify the connection string to point to a database that does not yet exist and run update-database. It will run all the migrations in order.
As far as migrating to the Production database, I am running the update-database command with the -script switch to acquire the raw sql and then applying that script to the production database manually. This is helpful if you need to keep a record of sql commands run against the database as well. Additionally, you can generate the script explicitly from a specific migration to another specific migration via some of the other update-database switches.
Alternatively, you can create an Idempotent script that works from any migration by using the–SourceMigration $InitialDatabase switch and optionally specify an end migration with –TargetMigration
If you delete the _MigrationHistory tables you will have issues where the generated script will be trying to add columns that already exist and such.
You may find the following link helpful:
Microsoft Entity Framework Migrations
I would suggest having a separate trunk in your source code repository - one pointing to production and one to development to avoid risks of switching between the two in visual studio.
Me also had the same problem, even when using one and the same database - due to some merges in the repository, and the mix of automatic/manual migrations. For some reason the EF was not taking into account the target database, and calculating what scripts need to me executed, based on what is already in the database.
To fix this, I go to the [__MigrationHistory] table on the target database and get the latest migration name. This will help EF to determinate the state of the DB, and will execute just the scripts needed.
then the following script is run:
update-database -script -sourcemigration {latest migration name}
This creates update script that is specific to the target database (the connection string should be correct, as discussed in the other comments)
you can also use -force parameter if needed
this way you can update any database to latest version, no mater in what version you found it, if it has MigrationHistory table.
Hope this helps
My production and my developmental database went out of synch and it gave me endless problems. I solved it using a tool from Red-Gate to match up the databases. After using the tool, the databases were exactly the same but my migration was not working and I started to get odd errors i.e. trying to add tables/ columns that already existed etc. I solved that. I just deleted the migration folder on the local, recreated it, added the initial migration, updated the database and then matched the data of this migration file (local) to the one on the host (delete all the data in the migration file on the host, and add the same data that is on the local into the host). A more detailed explanation is at:
migration synch developmental and production databases
I created some classes, and configured the connection string.
But still got an error:
Unhandled Exception: System.NotSupportedException: Model compatibility cannot be
checked because the database does not contain model metadata. Model compatibility
can only be checked for databases created using Code First or Code First Migrations.
Check the EF version you have, latest is 4.3.1.
You also need to configure a DbContext class. check this: http://msdn.microsoft.com/en-us/data/gg685467
i fixed it
by Run the ‘Enable-Migrations’ command in Package Manager Console.
Here is what worked for me if you are fine with deleting and recreating the database from scratch.
First, run the following commands from package manager console.
sqllocaldb.exe stop v11.0
sqllocaldb.exe delete v11.0
Next, delete the mdf and ldf files from the app_data folder of your project.
Here comes the critical part. Usually you will run update-database. If you do that the exception will still be thrown.
DO NOT Run update-database. INSTEAD directly run your project code. The EF will recreate the database.
These steps worked for me. Let me know if this helps you.
It looks like CodeFirst stops doing its homework when it doesn't have full control of the database (I suppose).
The scenario is a web site hosted on Arvixe.com (or I suppose any other shared hosting server), where I have to create databases only from their control panel (and NOT with Sql Server Management Studio, just to say...).
Once created an empty database, I register a connection in the web site, and I use it to generate database from poco objects like in:
add-migration m1 -targetdatabase myconnection
This generates correctly my FIRST migration, that I can apply without problems with
update-database -targetdatabase myconnection
The first concern, not too important, is that since the database is existing, it will NOT issue the Seed command, so I have to insert my first records by hand, but this is not a great problem.
Then I change my poco objects, and I need to update the database, but when I issue ANOTHER
add-migration m2 -targetdatabase myconnection
it gives the error:
System.Data.Entity.Migrations.MigrationsPendingException: Unable to generate an explicit migration because the following explicit migrations are pending: [201111081426466_m1]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
This is really strange, since if I look at the database, I can see even the table __MigrationHistory, but then it looks like it cannot recognize it...
Anyone with the same problem, or some good tip to where investigate?
Thanks in advance,
Andrea Bioli
I had this problem. I was able to resolve it by providing a connectionString and a connectionProviderName parameter to both the Update-Database and the Add-Migration commands.
If you have many projects in your solution with multiple config files, Package Manager seems to be confused. In my case, I had one project selected as the default project for Package Manager Console, but it was pulling the connection string from the Visual Studio solution default start-up project instead.