We Keep Coding

There is already an object named 'BookInvestments' in the database

I know a lot of answer for this question is available here but I have tried all out and not working. Maybe because my issue is different..
So i have an application already already in use with code-first approach. More than a year now. But there is the need to add some functionality which requires new fields to existing tables and also additional tables.
I am done adding this on local system. I want to do migration for it but bringing error
There is already an object named 'BookInvestments' in the database BookInvestment is an already existing table in the database by the way..
I have deleted the migration table on the Database and issue persist.
Please note that the namespace of the application remains same
I have also deleted the files created in the migration folder on my visual studio in trying to create new migrations and update database but issue persist.
I have records in the database and I cannot discard it as client has to make use of it going forward as well.
Please what do you suggest I do?

Entity Framework Migration: Why does it ignore snapshot and take __MigrationHistory into account?

I'm using EF 6.0.0 and .Net 4.5.
I face a very confusing problem. Me and one of my colleagues are working on the domain model section of our project on two different clients. The problem is:
1- Me and my colleagues start with the absolutely identical project and we are completely synced with the source control.
2- When I change the model for example add a property then Add-Migration FromA then Update-Database it works great. The generated code file contains just one command that is to add the column.
3- Meanwhile, after the db is updated and just before I check in something to source control, my colleague adds another property and then Add-Migration FromA then Update-Database. And guess what? This generated code file has a command to drop the column I newly added!!!
I added another column using native Sql, and fortunately the column is not going to be deleted.
I deleted the __MigrationHistory table and the remove column didn't get generated.
I turned off initializer Database.SetInitializer<MyContext>(null), no success.
So, my guess is that EF Migrations compares current model with the last one stored in __MigrationHistory table not the last local snapshot stored in .resx file. Am I right? Any way to solve the problem?

There are no pending changes for EF migration and still it complains that there are pending changes. How does EF keep track of this?

I have several migration files in my project and since I made manual modifications to my last migration I don't want to re-generate it with the "package manager console". I only need to add 1 column. So Added this manually a previous migration (I can do this since no-one has upgraded yet).
Now, when I start my project, the local database seems to create my new column fine but I do get an exception:
"Unable to update database to match the current model because there are pending changes and automatic migration is disabled"
It looks like the only way I can solve this is to generate an extra migration - even though, this migation generates exactly the same line of code that i wrote manually in a previous migration...
I was wondering - how does EF keep track of this and is there a way to bypass it ?
Also another question - is it wrong of me to want to limit the amount of migration files that I have ? I currently feel that in an ideal situation each Release of my software should only have 1 migration file at most in order to keep a better overview of my code...
thank you,

EF saves a hash of your serialized Model in the _MigrationHistory table, and compares them when you use migrations to ensure the database schema matches the model. I do not advise trying to bypass this. If you wish to mimimise the number of files then you can rollback then combine the migrations. But I don't think it's worth it. I just put my migrations into sub-folders periodically
I recommend this article:
http://elegantcode.com/2012/04/12/entity-framework-migrations-tips/

Check the table called _MigrationHistory in your Database. This will have the history of migrations you ran.
I don't think single migration is such a good idea. Because:
Each migration is like a version of the Database. You can go back to any version by doing "update-database -target migration MigrationName".
If many people are working on the project, it will become very difficult to keep track of what version is your DB is in and it will get messy.
If you want to add an extra column you can -force it to previous migration. Otherwise it is better to have multiple migration to avoid the confusion.

Rename table with Code First in Entity Framework

Does anyone knows if it is possible to just rename a database table with Code First in Entity Framework 5?
I just have simple models and a database initializer, but since my database already contains data I've commented that initializer out. So, I don't want to drop and create a whole new database.
When I add new columns to such a model I use the Package Manager Console and run update-database. to update my database. Does this also work for renaming tables? Does the update-database command automatically knows what the old name was?
I don't have a lot of experience with CF yet and learning new stuff every day. Without CF it's 'easy' to just run an alter table command and refresh the dbml file... But with CF? I don't have a clue!

use
<Table("TableName")> _
Public Class ClassName
....

Obviously the update-database command knows what the old name was... So, in case of data loss warnings, you may choose to apply the -force option.

How can I stop Add-Migration checking my database has no pending migrations when using Code-Based migrations?

I'm investigating using Code-Based EF Migrations for a product that does not use EF. Everything generally works well, except that the command:
Add-Migration MyTestMigration
outputs the following message:
Unable to generate an explicit migration because the following explicit migrations are pending: [201206260845338_DannyTest]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
The reason for this is that the connection string is not known at build time, and EF has randomly created a database called "MyContextName" on .\SQLExpress. I cannot apply the pending migration, because it references database tables that do not exist in this database - we're just trying to use migrations as a way of executing our scripts;
So the questions are:
If we're not using Automatic Migrations (we have EnableAutomaticMigrations=false), why does Add-Migration require that the database is up-to-date even though it has absolutely no impact on the generated (empty) migration? I find it hard to believe MS don't intend this use case when so much of it works; the only "broken" thing is validation that doesn't affect any behaviour.
Is there any way around this other than creating our own Add-Migration command that just duplicates what the EF one does, but skips the (seemingly needless) DB up-to-date check? I've tried passing various arguments, but so far not managed to make it work.
Edit:
I actually found a better way to solve this problem, but it's not really an answer to these questions, so adding it here. Hopefully will get time to turn this into a blog post!
The only reason I wanted to use Add-Migration was because of all the guff that went along with the DbMigration; but I realised that with a base class, we could basically eliminate the need for all this by having the base class auto-generate the migration ID from an attribute. The Target is identical for all our migrations, as the model state doesn't change. Now, we just manually create our migrations like this (the date is required to build the ID such that EF will apply them in the correct order):
[Migration(2012, 6, 27, 12, 00, "Add new xxx fields for yyy")]
internal class MyNewMigration : MyDbMigration
{
public override Up()
{
// ...
}
public override Down()
{
// ...
}
}
The MyDbMigration class has the Target/Source/Id properties. Target is hard-coded (the same value that Add-Migration created with the first migration), Source is null, and Id is some reflection that reads the MigrationAttribute. This means we can now just manually create these classes; which isn't a lot of effort now we don't have to worry about all the IMigrationMetadata stuff :-)

Try commenting out your existing migrations (the ones that haven't been applied to the database created on .\SQLExpress) and re-running your app. That should populate the local database with the initial tables it needs.
Once the local database has the correct structure you should be able to uncomment your migrations and then use update-database to bring the local one up to date. Then you'll be able to add a new migration.
Also remember that there's a -connectionString parameter on the update-database command, so you can target your migrations at a specific server/db.

I was seeing this error until I deleted from the Solution the original auto-generated migration code that the Package Manager had initially created.
This would have been 201206260845338_DannyTest.cs in Danny's case.