Unable to see SQL Server 2008 tables within entity framework designer of visual studio 2010 after moving database to new server

Question

I'm having trouble seeing tables from one particular SQL Server 2008 database while trying to update the entity framework diagram (EFD) in Visual Studio 2010. This was working before moving the db to the new server. All other DBs on this server show their tables successfully (when in VS Entity Framework design > Right Click > Update Model from Database > 'Add' tab > Expand tables = nothing showing here).

STR

1. I created a database on computer A and was working on the same computer in Visual Studio 2010 to build a website app. Everything was working fine.

2. I then moved the DB and website app files to the primary server, computer B.

3. I tried to connect from VS of computer A and was unable to see any database tables while trying to update my EFD.

4. I tried opening the VS locally on computer B and I can still not see the EFD tables.

5. I tried backing up / restoring the DB to see if it was an OS file issue. <- no luck

6. I tried to create a new db and use the scripts generated in SQL Server to build the new db with no luck.

7. I've also tried changing the owner of the db, moving to sql authentication and back to windows auth and even adding security to different users that I would assume are unrelated (such as system and guest).

I believe it is a permission issue, but I can't seem to find any differences in the DBs that work (show their tables properly in entity framework designer) and this one that doesn't. I also can't see what user VS may be using to get the table information, I would assume the one that I've setup the connection for but not sure.

I'm totally stuck. In the entity framework designer I'm trying to connect using a "System.Data.SqlClient", windows integrated authentication (which should be using an admin account on the system and the owner of the db). Connection string for the entity framework is as follows:

metadata=res://*;provider=System.Data.SqlClient;
    provider connection string="Data Source=localhost;Initial Catalog=myDB;
    Integrated Security=True"

One last note - If I just go into VS on the top right into my Server Explorer I can create a connection there and see all of the tables just fine. However, that doesn't help me with my EFD, unfortunately.

Answer 1

It may be different versions of your entity framework, but something seems missing from those connection strings, mine look like this:

 connectionString="metadata=res://*/xxx.csdl|res://*/xxx.ssdl|res://*/xxx.msl;provider=System.Data.SqlClient;provider connection string="data source=xxx;initial catalog=xxx;integrated security=True;multipleactiveresultsets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />

I have a bunch of stuff before the provider declaration.

Also have you tried deleting the connection string on the .config file and re-running the wizard as stated in this answer: How should I edit an Entity Framework connection string? ?

Finally, have you tried just generating another .edmx file with the connection that works? I guess this isn't that create if you made a lot of custom changes to your object layer that doesn't match your db design.

Answer 2

Steps to troubleshoot:

1. Create new blank database
2. Generate scripts off of the old
3. Run scripts one by one to see what breaks it (each table, view, etc one by one)

I found that this worked fine and nothing broke it, but the difference is that I did not create the new schema and user NT AUTHORITY/SYSTEM until the very end of the scripts where they were being created at the beginning when running the full script previously (and it wasn't working). I have no idea why this would be an issue - all tables were created with the 'dbo.' prefix anyways so should not have been put in this schema.

With that in mind I went into my original db and simply deleted the schema and user login for NT AUTHORITY/SYSTEM and all is working fine. Again, I'd love comments if anyone has any.

All is working now, I even re-mapped this user's security to allow public access to the db again and created a default schema for it under the same name and it works fine. I really can't explain this one.