Change Entity framework database schema at runtime

Question

In most asp.net applications you can change the database store by modifing the connectionstring at runtime. i.e I can change from using a test database to a production database

Answer 1

The connection string for EF is in the config file. There is no need to change the SSDL file.

EDIT

Do you have the prod and test schema in the same database?

If Yes you can fix it by using a seperate database for prod and test. Using the same schema name in both databases.

If No you can fix it by Using the same schema name in both databases.

If you will absolutly have different schema names, create two EF models, one for test and one for prod, then select which on to use in code based on a value in your config file.

Answer 2

Here is a similar question with a better answer: Changing schema name on runtime - Entity Framework

The solution that worked for me was the one written by Jan Matousek.

Answer 3

I have this same issue and it's really rather annoying, because it's one of those cases where Microsoft really missed the boat. Half the reason to use EF is support for additional databases, but unless you go code first which doesn't really address the problem.

In MS SQL changing the schema makes very little sense, because the schema is part of the identity of the tables. For other types of databases, the schema is very much not part of the identity of the database and only determines the location of the database. Connect to Oracle and changing the database and changing the schema are essentially synonymous.

Answer 4

Update Upon reading your comments it's clear that you're wanting to change the referenced schema for each DB, not the database. I've edited the question to clarify this and to restore the sample EDMX you provided which was hidden in the original formatting.

I'll repeat my comment below here:

If the schemata are in the same DB, you can't switch these at runtime (except with EF 4 code-only). This is because two identically-named and structured tables in two different schemata are considered entirely different tables.

I also agree with JMarsch above: I'd reconsider the design of putting test and production data (or, actually, 'anything and production data') in the same DB. Seems like an invitation to disaster.

Old answer below.

Are you sure you're changing the correct connection string? The connection string used by the EF is embedded inside the connection string which specifies the location of CSDL/SSDL/etc. It's common to have a "normal" connection string for use by some other part of your app (e.g., ASP.NET membership). In this case, when changing DBs you must update both of your connection strings.

Similarly, if you update the connection string at runtime then you must use specific tools for this, which understand the EF connection string format and are separate from the usual connection string builder. See the example in the link. See also this help on assigning EF connection strings.

Answer 5

Sorry its not a robust answer but I found this project on codeplex ( as well as this question ) while googling around for a similar problem:

http://efmodeladapter.codeplex.com/

The features include:

• Run-time adjustment of model schema, including:
• Adjusting data-level table prefixes or suffixes
• Adjusting the owner of database objects

Some code from the docs:

public partial class MyObjectContext : BrandonHaynes.ModelAdapter.EntityFramework.AdaptingObjectContext
{
        public MyObjectContext() 
        : base(myConnectionString, 
        new ConnectionAdapter(
            new TablePrefixModelAdapter("Prefix", 
                new TableSuffixModelAdapter("Suffix")), 
        System.Reflection.Assembly.GetCallingAssembly()))
    {
    ...
    }

}

Looks like its exactly what your looking for.

Answer 6

Solved my problem by moving to sql server and away from mysql.

Mysql and Mssql interpret "schemas" differently. Schemas in mysql are the same/synonyms to databases. When I created the model the schema name..which is the same as the database name is hard coded in the generated model xml. In Mssql the schema is by default "dbo" which gets hard coded but this isnt an issue since in mssql schemas and databases are different.