I got this error:
"The table/view 'database.dbo.table' does not have a primary key defined and no
valid primary key could be inferred. This table/view has been excluded. To use
the entity, you will need to review your schema, add the correct keys, and
uncomment it."
So, I un-commented it, added EntityKeys, EntityTypes, and a query. Everything worked fine, until I "Update Model From Database", which erased all my changes.
How can you get Entity Framework to recognize the view under the "Update Model From Database"? Is there anything you can add to the Microsoft SQL 2005 view so that EF could pickup as the primary key fields?
My view only has two fields:
ID int not null, -- PK
SKU int null
This is a known EF Designer limitation. The Store part of the model is regenerated by the Update Model From Database wizard, this is the reason of the problem.
This problem was already discussed at the Devart Entity Framework Support forum here.
Related
I have 3 tables
Brands:
BrandID int
BrandName varchar(30)
Products
ProdID int
ProdName varchar(30)
BrandToProd:
BrandID int => FK Brands.BrandID
ProdID int => FK Products.ProdID
After generating model from existing database EF omits BrandToProd table and creates Many-To-Many relationships between Brands and Products. I would like to have third entity with following fields:
BrandName varchar(30)
ProductsName varchar(30)
This will give me possibility to use scaffolding for this entity. Ideally, when I'll add new pair of Brand and Product, EF should check first if such Brand or Product already exist in database (to avoid duplicates), if no, add to corresponding tables and that add mapping to BrandToProd table. If Brand or Product already exist, EF should you existing BrandID/ProdID value when adding to BrandToProd table. Is there any idea how to do that?
Your BrandToProd table is a pure junction table, i.e. a table with only two foreign keys. It is an EF feature to model such tables into a many to many association without a class in the conceptual model.
The easiest way to include a pure junction table in the model as an entity class is
add a dummy field to the database table temporarily
generate the model
delete the field from the database
update the model from the database
delete the property in the edmx diagram
An alternative way is to edit the edmx manually, but then you really need to know what you're doing. If you don't want to regenerate the model you could generate a second model and investigate the differences in both edmx files by a difference viewer.
However, I wonder if you need to do this. You seem to relate this to duplicate checking. But if you want to add a Brand or Product to the database you'll have to check for duplicates either way. If you want to add a new association (e.g. adding an existing Brand to Product.Brands) you don't have to check whether it exists. If it does, EF just ignores the "new" association.
As extra point to Gert's answer:
when using surrogate keys, there is always the issue of duplicate management. Normally there is 1 or more fields that make a logical key.
you can
a)create a unique index on the Db. Db will complain when the constraint is violated
b)Execute a logical duplicate check before attempting an insert.
I've ended up with just adding dummy ID field to my junction table, as I'm frequently changing DB schema (becsuse site development is in progress and I need from time to time update model from database) and don't want to each time remove/add dummy field to database. Another option I've used - SQL View on two tables and stored procedures mapped to corresponding actions (CRUD) in EF
I'm relatively new to Entity Framework.
I created a database with two tables: Accounts and Assignments.
Accounts has an AccountId primary key which is used as a foreign key in the Properties table. I really like that the Entity Framework automatically picks up the foreign key relationship and allows me to access rows in Assignments as a property of each row from Accounts.
I went ahead and created a new View object that returns all the columns from Accounts along with some other information. However, when I get the data from the View in SQL using the Entity Framework, it is no longer automagically referencing the associated rows in the Assignments table.
How can I get the desired behavior using Views with Entity Framework
This can work in EF, but the EF designer can't infer your FK out of the view, since the DB doesn't tell it where the FKs on view columns are (since they're naturally on the underlying tables, not the view itself).
You'll need to manually edit your EDMX, either via the designer or in XML, to get these properties.
The solution that worked for me was to include the appropriate data in the view so I didn't need to use the FK.
For example, include the PK's for the Assignment table in the view by adding the appropriate SQL to the view.
That way I could join to the view in LINQ without needing to refer to a generated property in the EDMX.
Got an Excel file that contains nearly 10k rows. I transferred it with a Codeplex Guide and created a new DB with a table that contains all data.
When I use:
SELECT *
FROM RenewDatabase
It compiles and its soft clouds everywhere. When I add a ADO EF to my project, just for taking out all objects to a simple console application. I get the errorMessage:
The table/view 'DBO' does not have a primary key defined and no valid primary key could be inferred. This table/view has been excluded. To use the entity, you will need to review your schema, add the correct keys, and uncomment it.
Well, I have tried a lot of different ways to configure this. Now I have a table with a primary key that is the ProductID. It is located as a PK in the "Keys" directory...
Trying to refresh, reconnect and all, but nothing changes. I still have the problem that the map over my DB aint showing. Neither of my properties or columns is in the Visual Studios Data Model Designer.
DBO is usually the default database schema, not a table. Maybe your context has gotten confused somewhere?
Assuming this is a database-first approach (i.e. you have created an EDMX with the WYSIWYG editor), I would recommend you delete all your entities and re-import them. The database-first update wizard does not refresh renamed / re-defined relationships or columns (though it will add new ones), and it can be a bit confusing to sort them out manually, especially if you're not familiar with how DBMS's work.
The .NET Entity framework is giving me the following error:
"The table/view 'Foo.dbo.vwFoo' does not have a primary key defined and no valid primary key could be inferred. This table/view has been excluded. To use the entity you will need to review your schema, add the correct keys and uncomment it."
The view is a collection of a variety of tables and calculations. What I'd like to do is create a "logical key" using one of the columns that I know should be unique. I can't figure out how to do this in SQL Server Manager 2005 (not a DBA.)
Anyone know how I could accomplish this?
The EF can't find the PK, because VIEWs don't have PKs. However, if the view returns a unique column, you can tell the EF that this is the "PK."
It's explained in this tip: How to work with Updatable Views
I need to use tables from a DB which I cannot alter (using linked server).
So part of my schema is a view on these table and I cannot create an FK in my DB.
When I come to creating the association in ADO.NET Entity Framework I am getting problems because a second column on the table from the external DB has an index on it and the EF is creating an Entity Key for it (it's the name descr of the record - I think they just wanted to speed the ordering on it).
When I take the Entity Key off this column in the EF entity it complains that I need it because the underlying table has a key on it.
If I leave it in I cannot map it onto anything in the table mapping of EF.
Does anyone know what I should do please?
You will have to edit the XML and remove the column from the key. Find the <EntityType> tag in the <edmx:StorageModels> section (SSDL content). Delete any <PropertyRef> in the <Key> that is not actually part of the primary key.
Once you do this, you can set "Entity Key" on the corresponding scalar property in the designer to false, and EF won't get mad. You will also not be asked to map this column in associations anymore.