I have a View in an SQL Server Database, which involves many different tables. I am using Linq to Entities to access the database, so I have no problem getting and showing view's result.
But the problem is when I want to modify some field in those results. As long as a view doesn't have a primary key, the Entity is read-only, so the question is:
Is there any way to modify the object with the view's data and save those changes in the corresponding tables?
Sorry for my english, but it's not my native language.
Thank you very much in advance!
There are some requirements for VIEW to be updatable. Take a look here. You say your view references many tables, so you have to implement INSTEAD OF trigger.
Related
I use Entity Framework in combination with an Oracle database. If I create a query like
myLinqStatement.ToListAsync()
I get wrong data returned as a result. If I change the statement to
myLinqStatement.AsNoTracking.ToListAsync()
I get the correct data.
I also checked the native SQL query, which is generated by myLinqStatement.ToListAsync(). The generated SQL query is correct, because I get the correct data.
So is there a problem in the mapping? And why is it working with AsNoTracking?
Thanks!
What AsNoTracking does is to retrieve the data without attaching it to the context, hence any changes you apply over the data do not take effect unless you attach it again so that EF knows it should track its changes.
The code snippets you've provided do not show the whole picture, from the moment a context is created, but is it possible that other parts of your code mutate data before you call myLinqStatement.ToListAsync()?
As you mention that myLinqStatement.AsNoTracking.ToListAsync() returns expected data, makes me assume that there are some side effects in your code that AsNoTracking simply is not aware so just returns whatever it finds in your db
I came across this question because I had a similar issue with Entity Framework Core querying a DB view, the issue was cause because view didn't have a key defined, after defining a key for the entity that map to that DB view, the query returned the same result in both cases (using AsNoTracking or without using it).
In T-SQL a key for a DB view can be defined this way:
CREATE UNIQUE CLUSTERED INDEX UQ_MyDBViewName_ColumnKey
ON dbo.MyDBViewName (ColumnKey);
And in code, you can map the key using the [Key] attribute in the corresponding property of the entity or using the EF fluent API. It will depend of what the project is using.
Either way, using AsNoTracking on a query that goes directly to a DB view makes a lot of sense. Also, if for some reason the query of the view does not allow us to define a key for that view, then the option is to use AsNoTracking.
Hope it helps anyone else having the same issue.
My MVC2 app use LINQ to SQL as the ORM. I just drag and drop the tables from the SQL Server Explorer connection to the LINQ design surface. Two of the tables (A and B) are related. Table A has 3 foreign keys referencing Table B. In the LINQ design surface, I manually change the name of the parent property for these associations to give them more distinguished names. However, whenever I modify the table structure in the SQL Server, and drag and drop the new structure to LINQ, I would lose the names. Is there a way to prevent this from happening? Thanks.
No. When you drag the tables back to the designer, Linq to SQL regenerates the code in the partial class, obliterating your custom changes.
The only way to preserve the name change is to rename the affected table fields in the database.
You might be able to achieve such customization preservation with the T4 Toolbox.
It is always a bad idea to make the associations at the LINQ level. Make the associations at the table level. This will ensure that when ever you are doing a drag and drop of the tables, the designer class reflects the correct associations.
I am just getting into Entity Framework for the first time beyond simple examples.
I am using the model-first approach and am querying the data source with LINQ-to-Entities.
I have created an entity model that I am exposing as an OData service against a database where I do not control the schema. In my model, I have two entities that are based off of two views in this database. I've created an association between the two entities. Both views have a column with the same name.
I am getting the error:
Ambiguous column name 'columnname'. Could not use view or function 'viewname' because of binding errors.
If I was writing the SQL statement myself, I'd qualify one of the column names with an alias to prevent this issue. EF apparently isn't doing that. How do I fix this, short of changing the view? (which I cannot do) I think this does have something to do with these entities being mapped to views, instead of being mapped to actual tables.
Assuming you can change the model have you tried going into the model and just changing one of the column names? I can still see how it might be problematic if the two views are pulling back the same column from the same table. I can tell that when working directly with a model mapped to tables, having identically named columns is not a problem. Even having multiple associations to the same table is handled correctly, the Navigation Properties are automatically given unique names. Depending on which version of EF you used you should be able to dig into the cs file either under the model or under the t4 template file and see what's going on. Then you can always create a partial class to bend it to your will.
I have a doctrine data model with a table Person, however my Symfony application is only part of a bigger web application, which is build in Joomla. For a module, I need to add a number of fields from a view, which spans 8 tables with the person table. The view is already established for the Joomla part of things.
Short of creating a schema for all the tables involved, is there a way to arbitrarily join the view in my tableMethod? As another shortcut I am thinking of creating a minimal schema.yml table to just represent the field of the view that I need.
another solution would be to use native sql with doctrine
Have been trying out the new Dynamic Data site create tool that shipped with .NET 3.5. The tool uses LINQ Datasources to get the data from the database using a .dmbl context file for a reference. I am interseted in customizing a data grid but I need to show data from more than one table. Does anyone know how to do this using the LINQ Datasource object?
If the tables are connected by a foreign key, you can easily reference both tables as they will be joined by linq automatically (you can see easily if you look in your dbml and there is an arrow connecting the tables) - if not, see if you can add one.
To do that, you can just use something like this:
<%# Bind("unit1.unit_name") %>
Where in the table, 'unit' has a foreign key that references another table and you pull that 'unit's property of 'unit_name'
I hope that makes sense.
(EDIT misunderstood the question, revising my answer to the following)
Your LinqDataSource could point to a view, which allows you to overcome the problem of not being able to express a Join in the actual element. From "How to: Create LINQ to SQL Classes Mapped to Tables and Views (O/R Designer)":
The O/R Designer is a simple object relational mapper because it supports only 1:1 mapping relationships. In other words, an entity class can have only a 1:1 mapping relationship with a database table or view. Complex mapping, such as mapping an entity class to multiple tables, is not supported. However, you can map an entity class to a view that joins multiple related tables.
You cannot put more than one object/datasource on a datagrid. You will have to build a single ConceptObject that combines the exposed properties of the part Entities. Try to use DB -> L2S Entities -> ConceptObject. You must be very contrived if the DB model matches the ConceptObject field-for-field.
You are best using a ObjectDataSource when you wnt to do more complex Linq and bind your Grid to the ObjectDataSource.
You do however need to watch out for Anonymous types that could give you some trouble, but anything is posible...