Entity Model cannot accept View without id? - asp.net

SELECT DISTINCT TOP (100)
PERCENT country_Code, country_Name
FROM dbo.Location
Message 1 The table/view 'mixtapez.dbo.View_Select_Country' does not
have a primary key defined. The key has been inferred and the
definition was created as a read-only
table/view. E:\1C#asp.net\vuziq\vuziq\Projects\BannerSystem\WebBannerSystem\WebBannerSystem\Models\Model1.edmx 0 0 WebBannerSystem
The view works on others languages, so I dont want get Id by distinct, any idea?

It is just an informative message that Entity Framework created what it thinks is the primary key because any Entity Framework entity must have a primary key (that is .NET key, not SQL key). If you have read-only entity, the autogenerated key will probably work just fine for you. To be extra safe (and remove any chance the key does not work correctly), you should use NoTracking option for queries on this entity.
If you use .Distinct() in LINQ query that will go into your SQL query - the key Entity Framework uses does not play any role.

Related

asp.net Entity Framework/ Update from database/ The table/view does not have a primary key defined and no valid primary key could be inferred

One of the database view I am trying to import using entity framework contains only two columns, one is an integer type of column and another one is an aggregate function. I am getting the following error.
The table/view 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.
I understand it is a known scenario and it can be fixed by either including a Key column in the view or modifying the edmx file manually.
I just wanted to know if there is some other solution other than the above two? I do not want to include an additional column in my query and making changes in edmx is not feasible as DB changes are very frequent and the edmx will be overwritten every time I update from db.
You can mark both properties as entity key directly in the designer but you must ensure that the composite value of these two properties will be always unique. If you cannot ensure that you must add another unique column anyway or you may have some other problems when working with such entity set.

Dynamic Data Site doesn't filter by nchar field

I have 2 tables that have a foreign-key relationship through the field that has nchar type.
Database designer successfully created relationship and displays it on database diagram. But entity model created doesn't have this relationship, and as a result dynamic data site doesn't allow automated filtering by that parameter.
Is it possible to force that relationship be mapped to entity data model?
If no, how to apply filter on that field?
Dav Check if your foreign table have primary key or not. I faced same problem but after adding primary key to foreign it got resolved. Please try once.
If still you are facing problem you can use FilterUIHint annotation to do it.

How to implement a cross-database foreign key constraint?

Let's say I have two schemas: HR and Orders.
[HR].Employees [Orders].Entries
-------------- ----------------
Id_Employee ----> Employee
Fullname Id_Entry
Birthday Description
Amount
As you can see, what I'd want is to be able to establish a cross-database foreign key, but when I try this using a database link, I get:
-- From [Orders]
ALTER TABLE Entries
ADD CONSTRAINT FK_Entries_Employees FOREIGN KEY (Employee)
REFERENCES Employees#HR;
COMMIT;
ORA-02021: DDL operations are not allowed on a remote database
Is there a way around this? It's a legacy database, so I can't change the existing schema.
For the NHibernate crowd: I would then use this relation to map the NHibernate's domain objects.
One option would be to create a materialized view of Employees on [Orders] and then use that as the parent for the foreign key.
Of course, that has some drawbacks. In particular,
-- you won't be able to do a complete refresh of the materialized view without disabling the foreign key, so it'll have to fast refresh.
-- keys entered into EMPLOYEES won't be available to ENTRIES until the materialized view refresh. If that's critical, you may want to set it to refresh on commit.
Other alternatives are to handle the key enforcement yourself through a trigger or through a post cleanup process. Or convince the DBA's that these schemas can reside on the same database instance.
As far as I know constraints and referential integrity are only supported within one single database.
If you need to cross the boundaries of the database, you'd have to be creative. Maybe write some triggers checking for data in the other database or enforce these constraints on the application level. But then you may encounter the problem with transaction scope limited to one single database.

Update Data Model Business Entity

I have web application where Iam using linq to business entites i have business data model.
the problem is :
I have table with one column that it dosen't allow null value, when I try to update this table the folloeing error arise:
error The property 'e.g Carrier' is part of the object's key information and cannot be modified
what I can do?
The easiest thing to do is add a second column to the table that has a unique key eg guid and create a read only property on the entity that corresponds to it.
Linq to business entites needs some kind of key to keep track of what to update in the database. Usually this is the primary key on the database table. If you dont have a primary key it cannot reliably update the database and will then send you an exception.
Also if there is no primary key explicitly set on the table linq to business entites will select one of the columns (think its the first column in the table but i could be wrong) to act as a primary key and will therefore not allow you to update it.

Should I use a composite key for a map table, which is also used for a foreign key?

I am using ASP.NET and the Entity Framework to make a website. I currently have a map table for a many to many relationship between... let's say users and soccer teams. So:
Users
Teams
UserTeams
Part 1: Is it best practice to use a composite key for the primary key of the map table? In other words:
UserTeams table
PK UserId
PK TeamId
PreferenceId
Part 2: The caveat is that I also have another table. Let's call it "UserTeamPredictions" that stores the user's predictions for a given team for each year. That table has a foreign key that points back to the map table. So it looks something like this:
UserTeamPredictions table
PK UserTeamPredictionId
FK UserId
FK TeamId
Prediction
PredictionYear
This seems to work fine in the Entity Framework, however, I have had some problems when referencing relationships in third-party controls that I use like Telerik. Even though it might not be the ideal data setup, should I change the table structure/relationships so that its easier to work with in the code with data binding and other things?
The change would be to add an integer primary key to the UserTeams map table, allowing the UserTeamPredictions table to reference the key directly, instead of through the composite key as it currently does:
UserTeams table
PK UserTeamId
FK UserId
FK TeamId
PreferenceId
UserTeamPredictions table
PK UserTeamPredictionId
FK UserTeamId
Prediction
PredictionYear
What do you think!?
You should change it. Search stack overflow for discussions on "natural keys" - it's almost universally agreed that surrogate keys are better, especially when using entity generation. Natural or composite keys do not play well with entity framework style DAL layers in general. For example, Lightspeed and Subsonic both require that you have a single unique column as a PK... Lightspeed in it's current version even goes so far to insist that your column is called "Id", although that will be changing next version.
I would choose not to. I would use a surrogate key and put a unique index on the UserId and TeamId columns. I get really sick of composite keys when there are more than two, and rather than have a mix of composite and surrogate keys, I choose to go with all surrogate, meaningless autoincrement keys wherever possible.
This has the bonus of giving you good performance on joins, and means you always know the key for a given table (table name + ID), without having to reference the schema. Some ORM tools only work properly with single column rather than composite keys, too.

Resources