We Keep Coding

EntityFramework Schema specified is not valid

I know this question was already asked but it seams that my case might be slightly different. I tried the "run custom tool" but here's where the strange thing happens: Because i'm having 2 related databases (so 2 related models). If i'm running the custom tool on one model it screws up the other and vice-versa(incomplete .cs files, missing, etc.). Does anyone have any ideea where i'm going wrong?
EDIT:
the complete error:
An exception of type 'System.Data.Entity.Core.MetadataException'
occurred in EntityFramework.dll but was not handled in user code
Additional information: Schema specified is not valid. Errors:
The relationship
'ProductionMasterDataEntityModel.FK_ProductGroup_CostPeriods' was not
loaded because the type 'ProductionMasterDataEntityModel.ProductGroup'
is not available.
The following information may be useful in resolving the previous
error:
The required property 'CstAveOrderQty' does not exist on the type
'SISCOM.Persistance.Models.ProductGroup'.
The custom tool is: TextTemplatingFileGenerator
I'm not sure if it has anything to do with the asp.net framework but it is an asp.net project so i thought it's worth mentioning.

in my case, this Issue came after I update .edmx file. Remove all the tables on it and re-update it.right click on .tt file(Eg. Entity.tt) file->Run custom tools. then my issue solved.

I solve this case like below.
Entity in class lib project and i was try to consume in other project.
So in that project i have add reference "EntityFramework.SqlServer.dll" in new project.

Drop the model from edmx and add it again should sort it out. Note this cannot be reverted unless using source control tools.

It seams that i had 2 problems contributing to that error.. First, there were some stored procedures and views, after i got that out of the way (deleted my models, created them again and i've unchecked the option to include the stored procedures and i only added the tables to the model, no views and no stored procedures) i could access some data but not all of it.. The second problem was that i forgot to add a connection to the dependent database.
So the methods in my repository look like this:
public myType GetSomething()
{
var db = new model();
var dependencyDb = new dependencyModel();
//do whatever needs to be done with the data before presenting it
return something;
}
P.S... i didn't had to explicitly take it to the needed table, after i added the connection it found all that it needed by itself.
Hope this helps anyone having this problem.

Entity Framework DbContext compatible with different databases

Using Entity Framework, I have created an application which is able to read data from the database it was modeled against. I now have another database, with the same tables, hosted on another server.
The problem is that the tables on the second database belong to a schema with a different name to the original, so simply changing the connection string for my context in the app.config file doesn't work. (I get the error "table or view does not exist"). There must be some mapping somewhere in the auto generated code stating the original schema name.
What is the correct way to handle this kind of situation?
I don't really want to have to re-model the second database as it is identical to the first.
I can't change the databases as other applications would stop working.
Any nudge in the right direction would be greatly appreciated.

OK, so here's what I've done to solve this.
As #Kelmen mentioned in the comments, opening the EDMX file in a text editor revealed that this is where the schema information is stored. So I think I could have simply cleared out the value of the schema attribute and used the connection string to drive the schema.
This didn't feel right for a couple of reasons:
If the model was refreshed at any point, it might have repopulated the schema names, which would be REALLY annoying. I didn't have time to test if this would actually happen.
This method wouldn't let me control the schema name if I did need to change it at runtime.
The solution was to use Code First and the Fluent API to edit the model configuration in the OnModelCreating event within my derived DbContext class.
I'm now considering modifying my context class so that I can pass in the name of the schema or possibly drive it from my app.config.
I found the links tutorials to be quite useful:
Change Schema of Entity Framework
Entity Framework Change Schema Name Per Connection

How to get the project name when running website/web application?

I have a website and a web application that both log to a common error table. I want to be able to know which project logged the error. But I cant do it with some global property. I would like to get the project name through reflection. Is this possible? Is it even kept in the manifest and will be be available no matter what symbols the projects have been built with?

Try with below
System.IO.Path.GetFileName(System.Reflection.Assembly.GetExecutingAssembly().Location)
Ref Link::: Get executing assembly name using reflection
http://forums.devshed.com/net-development-87/c--get-project-s-name-via-net-object-483704.html

"Project" is purely a VS/MSBuild concept and as such does not exist outside of realm of these tools. What I can suggest instead is to use first "segment" of a namespace of Global.asax-"derived" application.
var applicationName = typeof(Application).Namespace.SubstringBeforeFirst(".");

i see two solutions (assuming your error table is SQL-based)
dupe error table and "give" eachproject its own to write into, then if you need to aggregate them you can make up a simple union in a view (you can then have project name in the resulting table based on where the records come from)
add a column "project name" to the error table, then fill it when you write your error (since every project knows what's his name when it writes, it's a trivial task and hardcoding this data wouldn't smell too much)
if you have restricitons, please explain what where and why so we can help more easily.

Change Entity framework database schema at runtime

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 by simply changing the value of the "database" field in the connectionstring
I'm trying to change the schema (but not necessarily the database itself) with entity framework but no luck.
The problem I'm seeing is the that the SSDL content in the edmx xml file is storing the schema for each entityset.
see below
<EntitySet
Name="task"
EntityType="hardModel.Store.task"
store:Type="Tables"
Schema="test" />
Now I have changed the schema attribute value to "prod" from test and it works..
But this does not seem to be a good solution.
I need to update evert entity set as well as stored procedures ( I have +50 tables )
I can only do this an compile time?
If I then try to later update the Entity model-entityies that already exist are being read due to EF not recognizing that the table already exists in the edm.
Any thoughts?

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.

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.

The easiest way to solve the problem is to manualy remove all entries like 'Schema="SchemaName"' from the SSDL part of the model.
Everything works propely in this case.

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.

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.

When I create a new "ADO.NET Entity Data Model", there are two properties "Entity Container Name" and "Namespace" available for editing in design view.. Using the namespace.EntityContainerName, you can create a new instance specifying a connection string.
MyEntities e = new MyEntities("connstr");
e.MyTable.Count();
I'm not sure if this helps you or not, good luck!
Also, this is a good case for multiple layers (doesn't have to be projects, but could be).
Solution
* DataAccess - Entities here
* Service - Wraps access to DataAccess
* Consumer - Calls Service
In this scenario, the consumer calls service, passing in whatever factor determines which connection string is used. The service then instantiates an instance of data access passing in the appropriate connection string and executes the consumer's query.

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.

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.

One or more files do not match the primary file of the database (error 5173)

I got this error when I checked out my database from source control. It might sounds weird to check in the sql server database, but this was what I have done because this is just a personal project.
Anyone knows how to fix this?

Here's my finding.
As mentioned by other posters, you really don't want to check database files into and out of the source control.
But if you absolutely need to, and you have done check in the database files and you are encountering the same error that I encountered, here is a workaround:
First, detach the database, then, delete the ldf file, reattach the database again.
This is how I solved my problem.

Did you take a copy of the log file (.ldf) as well as the ".mdf" file? You need the matching set of both to re-attach the database

You really don't want to be checking database files into and out of source control - in SQL Server you have to detach the files for this to even work and you run all kinds of risks.
If you absolutely have to do this, you should version backups.
I recommend versioning a script which creates the entire database (tables, sprocs, views, etc.)
You can try creating a database attaching from that data file and using Create Database the ATTACH_REBUILD_LOG option, but I'm not confident it's going to work since they probably weren't detached properly.

This sounds like the data files do not match the structure files of your database.
Shortly spoken, the files where your data (i.e. table rows) resides in are (mostly) not the files the structure of your data (i.e. the description of the tables) is stored. At least in "modern" RDBMS systems. So you checked out your data and the database recognized some changes in the structure which happened till then (you altered a table or something like that).
The way "to fix this" would be to check in all files your database relies on, but I think that is not really what you wanted to achieve. Better (as mentioned above) to do backups and then drop / restore the database from them.