I have a bigger project that uses multiple edmx files to manage the data model for an asp.net application. What I want to achieve is to link two entities accross two edmx models.
So basically, just a foreign key like this: EntityA.ForeignEntityId --> EntityB.Id
However, since the enitites are not in the same model, I cannot add this foreign key in the model designer. I know that I could do it manually by either modifying the auto-generated SQL-file or by adding the relation in the SQL Server Manager. Both these approaches have the massive downside that they are not easily maintainable because if I do "Create database from model" and run the resulting SQL script, my manual modifications are dropped (I thnink?).
So is there a way of referencing a foreign entity from another edmx model in the model designer?
I know this is old but i found myself with the same problem. If you create the reference in SQL and update your model from the database it will pull in the table that is referenced. I don't think this really solves the problem we have but it will at least allow for you to go back and forth without losing any FKs.
Related
I'm encountering a very odd problem. Since 2 days I cannot add new tables from my db in the model.
They appear in the list of addable tables, no error are shown at the validation but then, they don't appear in the Entity lists, and they still appear in the "addable" part of the menu.
The problem appears in
We've tried from different computeurs, so it's not a problem of my specific visual studio.
We've tried with other dbs, and the problem doesn't affect them. It affects boths of my prod and developpment dbs though.
We've tried with the exact same credentials to log to the db (not window authentication as we usually do), and the problem remains, so it's not a problem of rights.
We're a bit out of ideas right now :/
Does someone have an idea what it could be?
Thanks
Ok, we've found where it came from.
The table we wanted to add had no PK, and then when we tested we created mock tables without PK.
Once we add a PK the import goes well =)
If you're using a Code First approach then Entity Framework will build the table for you. It looks like you are not using Code First, so you will have create the table in the database. I assume you're using an Entity Data Model (.edmx)? If so, you will create your table in the database, then update your data model (.edmx). If you have not yet created your .edmx file, you need to do that - the .edmx file will contain all your CRUD operations.
What I'm confused about is I'd imagine your code would throw an error if the table did not exist (i.e. if the table represented by your data model didn't map to an actual table in the database, because it doesn't exist). So, the question is, does your table already exist? If it does, then step through the code line by line to find out why your records aren't being saved. If it doesn't exist, then add the table via SQL Server Management Studio (or similar), then open your .edmx file, right click on the layout that comes up, click "Update Model from database".
Is it possible to change relationships between tables in EF6 without losing data? From my research, my understanding is that many-to-many relationships can be configured using the Fluent API in the onModelCreating method.
What wasn't clear was whether I would be able to change a table from a one-to-many relationship to a many-to-many relationship with a junction table.
There isn't an explicit migration operation to move the data around like that, what you do is:
Alter your model as desired, either through the fluent API, POCO objects or designer.
In the Up method of the generated migration class, use the DbMigration.Sql method to move the data around in beween the generated Create/Add and Drop statements. Yes, this does involve manually writing the required SQL statements.
I created an application in Asp.Net MVC using the database first method. I generated my model using an edmx file. However i made a change to my context classes. Everytime i run my
application i get the following error:
"The model backing the 'ArticleContext' context has changed since the database was created. Consider using Code First Migrations to update the database"
Should i follow the advice the error gives me? Even though i used the "database first" method?
That depends. Database first approach doesn't only mean that you had the database first and you decide to create your model after that. It also means (in most cases) that database structure would really decide on how your model classes look like. Safest approach is to makde changes on the DB side and promoting them to your model by simply refreshing code from EDMX. If you really need to make some changes to the model classes, do it by implementing parital classes or ViewModels.
When migrating an Entity Framework 5.0 based project from code-first to database-first. We'll be using the standard VS2012 wizard to generate the edmx models off the database but do we have any additional steps beyond that? I presume I'd have to delete all classes where I've defined the code-first models and even the migrations folder - any other cleanup operations beyond those two?
[Edit]:
Reporting back.
So the actual experience was between my original expectations and what Ladislav mentioned (like he said, exact conditions are code dependant). For me the entire operation took about 15-20 minutes mostly involving
Branch creation (safety, in case stuff blows up!)
Removal of Code-first classes and source (I moved them outside VS2012 for a diff reference)
Creation of the EDMX model from the database (passing same namespace etc to the wizard to reduce the extent of differences)
Quick inspection of the code-first classes and the auto-generated db-first classes. This was mostly 1:1 since we used sensible names in the code first model to begin with.
Compiling and fixing each error one by one
Noticed many errors were due to automatic pluralization of EF 5 vs my own pluralization of different fields. Fixed 40+ errors via a quick case sensitive search-> replace all
Rerun all the tests after compiling
Merge feature branch back in!
Thanks
This may be quite complex if your entity or context classes contains any additional logic. You must:
Add EDMX model to your project and let it generate entity classes and context class
Remove migrations
If your original context class contains any additional code you must convert it to partial class with the same name, namespace and assembly as newly generated context class with only that additional code.
If any of your entity classes contained any additional code you must follow the same procedure as with the context.
If the additional code was actually called from inside of the code which is now auto generated you must make some other changes which may include changing code generation template and using partial methods.
You must remove any database initialization or migration execution from your bootstrapper
You must use the new connection string referencing metadata files
Another more complex option is not using auto generation feature and use your old context and entity classes but in such case you will have to keep them in sync with your EDMX manually.
I'm creating a data model first using the LINQ-To-SQL graphical designer by using right-click->Add->Class. My idea is that I'll set up everything first using test repositories, design the entire website, then as a final step, create a database using the LINQ-To-SQL classes as a model for the database tables and relationships. My reasoning is that it's easy to edit the classes, but hard to modify DB tables (especially if there's already data in them), so by doing the database part last, it becomes much easier to design the structure.
My question is, is there an automatic way to link the two once I have the DB tables created? I know you can manually fill out the class properties for the LINQ-To-SQL entities but this is pretty cumbersome if you have a lot of tables to deal with. The other option is to delete your manually-created classes and drag the tables from the database into the designer to auto-generate the classes, but I'm not sure if this is the best way of doing it.
Linq to Sql is intended to be a relatively thin ORM layer over a database. While you can of course just add properties to a data context and use them as a sort of mock, you are correct, it isn't really easy to work with.
Instead of relying solely on Linq to Sql generated classes to give you freedom from the database implementation, you may want to look into the repository design pattern. It allows you to have a smooth separation between your database, domain model, and your middle tier; I have used it on two projects now, and have been able to (for the most part) build everything top-down, leaving the actual database for last. Below is a link to a good tutorial on the pattern (better than I could scribble down here).
https://web.archive.org/web/20110503184234/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx
Depending on your database permissions, you may call your datacontext's DeleteDatabase() and CreateDatabase() methods as a ungraceful way of resyncing your classes and tables. This is not much of an option when you have actual data in the database, but does work when you are in your development stages.
Take a look at my add-in (which you can download from http://www.huagati.com/dbmltools/ , free 45-day trial licenses are also available from the same site).
It can generate SQL-DDL diff scripts with the SQL-DDL statements for updating your database with only the portions that has changed in the L2S model (e.g. add missing columns, missing tables, missing FKs etc), instead of the L2S-out-of-the-box support for recreating the entire db from scratch.
It also supports syncing the other way; updating the model from the database.