I'd like to know how to (if possible) associate tables from different databases using entity framework. I have one edmx for my "xyz" database and another for my "abc" I need to associate them using EF. I know how to fix this using FKs, but that's not what I want, I'd like to be able to do that using the visual editor, not adding, by hand, a FK to my DB.
Here's a pratical example of what I'd like to accomplish:
Table User - database: abc
Table Message - database: xyz
I'd like to associate User to Message and vice-versa.
Could anyone help me?
Thanks!
You can query them together with Linq-to-Objects, but not with L2S or L2E.
A context is wrapped around 1 Db-connection, you cannot track/update entites from multiple db's.
A possible workaround is to 'link' to one of the Db's from the other. MS-SQL can do this. To the EF it would appear 1 database.
There is no way to achieve this using the edmx design surface in EF.
You could encapsulate this association within your domain model and provide a distributed transaction across the two EF Contexts. We've implemented the latter with an EF Context "container" class that given an internal collection of contexts uses a TransactionScope when it contains more than one context (this relies on the IUnitOfWork abstraction to work effectively).
Related
Is it possible, in a code-first approach, to define two different context classes and use them simultaneously?
The database schema is already given and I cannot modify it (besides the creation of some new tables).
The problem I'm facing is that I'm getting "The model backing... has changed" error. It seems there's some kind of collision between the two contexts.
Note that each context includes a different set of tables, so sync problems aren't a concern.
Assuming you are using EF 6 or higher, this can be done either by the ContextKey-Property of DbMigrationsConfiguration (this will make the MigrationsHistory table multi tenant by ContextKey) or by setting HasDefaultSchema in OnModelCreating (this will enable multiple MigrationsHistory tables, one for each schema). For further instructions see the Documentation.
I would like to add new module (project) to my solution and to use entity framework code first only for subest of my database tables. I'm using ADO.NET with stored procedures in other modules. I plan to split tables from db in the future, but for now it is not possible (tables have no relations to other tables but are used by old modules) I'm not sure if it is good practise to do it in this way and I would like to ask for help.
is it possible to use EF code first for subset of the tables of my DB?
how to initialize these tables with code first? I found only solutions to drop whole
db if model doesn't match and recreate new DB. I need drop and recreate only
tables that are used in my project
is it good practise to use more approaches of the db access to one db?
do you see some problems in this approach? Now I see problem with concurency and data consistency ( if old module will operate with this tables in another approach )
Thank you.
1) Yes, it is. On one of our projects, we had database with store procedures which we migrated to use EF. But not at once. It had taken some time so we used Store procedures whit ADO.NET as well as EF together.
2) I must say I'm not sure about this. We had database already created with only few changes. But you could created tables by yourself.
3) I think better would be to call stored procedures from EF and use it on whole projects if you need them. But using both, ADO.NET and EF is ok, if you have reasons.
4) Why it would be problem if you will use transactions?
I have the following scenario:
I have a production database which is highly transactional. In order to keep queries efficient I would like to archive data from some of the tables to another database with exactly the same schema.
The relationships between tables are not very complex but any dependent objects would have to go with the archived data in order to uphold foreign key constraints.
Is there a simple way to do this using Entity Framework? I have tried to create two different contexts and add to one and delete from the other, but this is a bit of a tedious route.
If Entity Framework is not the best tool for this what is?
There is no simple way in EF5 to do this.
If your database is MSSQL you can make use of partitioning for archive tables (see http://blogs.msdn.com/b/felixmar/archive/2011/02/14/partitioning-amp-archiving-tables-in-sql-server-part-1-the-basics.aspx for more information).
They both seem to create classes based on a database schema. Why would you use the entity framework model over a table adapter?
They both allow me to easily drag a sql table onto a surface in Visual Studio, after which a class and all the code is generated which allows me to automatically create/update/delete records.
I know the entity framework is the clear choice, I just don't understand why.
Thanks!
Data-Set, Data-table and Data-row offers relational API - they are your RDBMS entities mapped as objects in .NET world. You can't have inheritance. You cannot have graph like structures.
EF on the other hand, allows you to model your objects as you want them to and then map that to RDBMS schema so that it would manage the persistence part. With EF, you can work with the conceptual (domain) model rather than relational model. For example, a EF entity might be projection from multiple tables or you can have several entities built upon a single table (e.g. inheritance scenario).
My situation is as follows. I'm using entity framework (4.0) in which I have defined a relatively simple model like, let's say, two entities:
user
transaction
A user can have multiple transactions in this scenario. When generating the database this would result (obviously) in 2 database tables names 'user' and 'transaction'.
The problem is that I want to use the code as a webservice where different companies should have their own environment (read: own users and transactions). A simple solution would be to add a column to both tables like, lets say 'company_id' to identify one user/transactions for companya from the user/transaction from companyb.
What I would like to have is a duplication of the tables like so:
compa_user
compa_transaction
compb_user
compb_transaction
This way..all data would be nicely separated and if company a generates a lot of transactions, company b would not notice that the system is getting slow or whatsoever.
My question: is there a way to accomplish this based on entity framework. So, can I have multiple tables representing one entity in my model and switch from table to table depending on which company is connecting to the service.
Any help appreciated!
If you really want to keep the tables seperate, then a seperate database for each client would be the easiest - only need to change the connection string in EF.
The other benefit of this model (seperate databases) is that the database will scale quite easily as each database could theoretically be on a different database server should the DB ever become the bottleneck.