i am working on a project using Entity Framework and now i got a situation where i need to use table valued function which returns table with 2 columns, hence i searched a lot and i came to know that we use table valued functions in Database first approach while i needed it in Code first.
here is the situation
i have a table with two columns
Table1
Id int PK
priority int
i want to use this table in my query in EF.
Is their any way i can use Table Valued function?
We can do this by using the c# code generated by the CLR for Database first approach
you can refer this url for the full description
http://blogs.msdn.com/b/adonet/archive/2011/06/30/walkthrough-table-valued-functions-june-ctp.aspx
i had used this code and it worked fine for me
[EdmFunction("NorthwindEntities", "GetDetailsForOrder")]
public IQueryable<Order_Detail> GetDetailsForOrder(Nullable<global::System.Int32> oid)
{
ObjectParameter oidParameter;
if (oid.HasValue)
{
oidParameter = new ObjectParameter("Oid", oid);
}
else
{
oidParameter = new ObjectParameter("Oid", typeof(global::System.Int32));
}
return base.CreateQuery<Order_Detail>("[NorthwindEntities].[GetDetailsForOrder](#Oid)", oidParameter);
}
I created a custom model convention which allows using store functions in CodeFirst in EF6.1. The convention is available on NuGet http://www.nuget.org/packages/EntityFramework.CodeFirstStoreFunctions. Here is the link to the blogpost containing all the details: http://blog.3d-logic.com/2014/04/09/support-for-store-functions-tvfs-and-stored-procs-in-entity-framework-6-1/
Related
We are using Entity Framework 6.0.0 and use database first (like this) to generate code from tables and stored procedures. This seems to work great, except that changes in stored procedures are not reflected when updating or refreshing the model. Adding a column to a table is reflected, but not adding a field to a stored procedure.
It is interesting that if I go to the Model Browser, right click the stored procedure, select Add Function Import and click the button Get Column Information we can see the correct columns. This means that the model knows of the columns, but does not manage to update the generated code.
There is one workaround, and that is to delete the generated stored procedure before updating the model. This works as long as you have not made any edits on the stored procedure. Does anyone know of a way to avoid this workaround?
I am using Visual Studio 2013 with all the latest updates as of early December 2013.
Thanks in advance!
Update 1:
andersr's answer helped in one case, where the stored procedure used a temporary table, so i gave him +1, but it still does not solve the main problem of updating simple stored procedures.
Update 2:
shimron's comment below links to a question about the same issues in EF 3.5. It seems the same is still true for EF 6.0. Read it for an alternative way of doing it, but my conclusion as of now is that the simplest way of doing it is to delete the generated stored procedure before updating the model. Use partial classes if you want to do something fancy.
Based on this answer by DaveD, these steps address the issue:
In your .edmx, rt-click and select Model Browser.
Within the Model Browser (in VS 2015 default configuration, it is a tab within the Solution Explorer), expand Function Imports under the model.
Double-click your stored procedure.
Click the Update button next to Returns a Collection Of - Complex (if not returning a scalar or entity)
Click okay then save your .edmx to reflect field changes to your stored procedure throughout your project.
Does your stored procedures return data from temporary tables by any chance ? EF does not seem to support this, see EF4 - The selected stored procedure returns no columns for more information.
However, the stored procedure will as you observed, be available in the Model Browser. I did a quick test featuring the scenario described above. The stored procedure was generated in my context class, but the return type was an int rather than a complex type. See the link above for potential workarounds.
I just encountered this and my workaround (it is really nasty) was to create an if statement with a condition that will never be true at the top of the stored procedure which selects the same list of outputs as the query with explicit casting to the datatypes I want to return. This will assume nullability of your types, so to resolve that you wrap the cast in an ISNULL
For example, if your output has the columns:
UserId (int, not null)
RoleId (int, nullable)
FirstName (varchar(255), nullable)
Created (datetime, not null)
You would expect this to create a POCO like:
SomeClass {
public int UserId { get; set; }
public int? RoleId { get; set; }
public string FirstName { get; set; }
public DateTime Created { get; set; }
}
...But it doesn't and that's why we're here today. To get around this not working as expected, I put the following at the top of my SP (right after the 'AS'):
if(1=0)
begin
select
UserId = isnull((cast(0 as int)),0),
RoleId = cast(0 as int),
FirstName = cast(0 as varchar),
DateTime = isnull((cast(0 as datetime)),'')
end
It is horrible and ugly but it works for me every time. Hopefully we get a tooling update that resolves this soon...happened to me today with no temp tables in SQL Server 2016 w/VS2015...
Hope this helps somebody
I have a legacy database with a particular table -- I will call it ItemTable -- that can have billions of rows of data. To overcome database restrictions, we have decided to split the table into "silos" whenever the number of rows reaches 100,000,000. So, ItemTable will exist, then a procedure will run in the middle of the night to check the number of rows. If numberOfRows is > 100,000,000 then silo1_ItemTable will be created. Any Items added to the database from now on will be added to silo1_ItemTable (until it grows to big, then silo2_ItemTable will exist...)
ItemTable and silo1_ItemTable can be mapped to the same Item entity because the table structures are identical, but I am not sure how to set this mapping up at runtime, or how to specify the table name for my queries. All inserts should be added to the latest siloX_ItemTable, and all Reads should be from a specified siloX_ItemTable.
I have a separate siloTracker table that will give me the table name to insert/read the data from, but I am not sure how I can use this with entity framework...
Thoughts?
You could try to use the Entity Inheritance to get this. So you have a base class which has all the fields mapped to ItemTable and then you have descendant classes that inherit from ItemTable entity and is mapped to the silo tables in the db. Every time you create a new silo you create a new entity mapped to that silo table.
[Table("ItemTable")]
public class Item
{
//All the fields in the table goes here
}
[Table("silo1_ItemTable")]
public class Silo1Item : Item
{
}
[Table("silo2_ItemTable")]
public class Silo2Item : Item
{
}
You can find more information on this here
Other option is to create a view that creates a union of all those table and map your entity to that view.
As mentioned in my comment, to solve this problem I am using the SQLQuery method that is exposed by DBSet. Since all my item tables have the exact same schema, I can use the SQLQuery to define my own query and I can pass in the name of the table to the query. Tested on my system and it is working well.
See this link for an explanation of running raw queries with entity framework:
EF raw query documentation
If anyone has a better way to solve my question, please leave a comment.
[UPDATE]
I agree that stored procedures are also a great option, but for some reason my management is very resistant to make any changes to our database. It is easier for me (and our customers) to put the sql in code and acknowledge the fact that there is raw sql. At least I can hide it from the other layers rather easily.
[/UPDATE]
Possible solution for this problem may be using context initialization with DbCompiledModel param:
var builder = new DbModelBuilder(DbModelBuilderVersion.V6_0);
builder.Configurations.Add(new EntityTypeConfiguration<EntityName>());
builder.Entity<EntityName>().ToTable("TableNameDefinedInRuntime");
var dynamicContext = new MyDbContext(builder.Build(context.Database.Connection).Compile());
For some reason in EF6 it fails on second table request, but mapping inside context looks correct on the moment of execution.
(as advised re-posting this question here... originally posted in msdn forum)
I am striving to write a "generic" routine for some simple CRUD operations using EF/Linq to Entities. I'm working in ASP.NET (C# or VB).
I have looked at:
Getting a reference to a dynamically selected table with "GetObjectByKey" (But I don't want anything from cache. I want data from database. Seems like not what this function is intended for).
CRM Dynamic Entities (here you can pass a tablename string to query) looked like the approach I am looking for but I don't get the idea that this CRM effort is necessarily staying current (?) and/or has much assurance for the future??
I looked at various ways of drilling thru Namespaces/Objects to get to where I could pass a TableName parameter into the oft used query syntax var query = (from c in context.C_Contacts select c); (for example) where somehow I could swap out the "C_Contacts" TEntity depending on which table I want to work with. But not finding a way to do this ??
Slightly over-simplyfing, I just want to be able to pass a tablename parameter and in some cases some associated fieldnames and values (perhaps in a generic object?) to my routine and then let that routine dynamically plug into LINQ to Entity data context/model and do some standard "select all" operations for parameter table or do a delete to parameter table based on a generic record id. I'm trying to avoid calling the various different automatically generated L2E methods based on tablename etc...instead just trying to drill into the data context and ultimately the L2E query syntax for dynamically passed table/field names.
Has anyone found any successful/efficient approaches for doing this? Any ideas, links, examples?
The DbContext object has a generic Set() method. This will give you
from c in context.Set<Contact>() select c
Here's method when starting from a string:
public void Test()
{
dynamic entity = null;
Type type = Type.GetType("Contract");
entity = Activator.CreateInstance(type);
ProcessType(entity);
}
public void ProcessType<TEntity>(TEntity instance)
where TEntity : class
{
var result =
from item in this.Set<TEntity>()
select item;
//do stuff with the result
//passing back to the caller can get more complicated
//but passing it on will be fine ...
}
I'm using EntityFramework 5 EDMX designer and would like to combine the first & last name of a person into a single field value (name, for instance) on the entity.
I thought in previous versions there was a way to do this, but I don't see anything available to do what I need to do.
Is this still possible?
Unless I'm not understanding your question, I believe I've done that with a partial class that resembles something like the following:
public partial class person
{
public string name {
get
{
return firstname + " " + lastname;
}
set{ }
}
}
No it is not possible. You can create model defined function and use it in queries but it will still not be part of your entity. If your entity is read only you can create database view with combined column and map it instead of the table - it shows also main reason why combining columns into single property is not such easy task. Automatic concatenating during reading is easy but automatic decomposing to save correct value into correct column is hard and error prone.
If you need combined property for anything else than querying you can simply create another partial part of your entity class and add your own computed property. If you need the combined property for querying use the model defined function.
The way I do this is through a Computed Column as explained here:
How to make a computed column nullable in SQL Server
If you use a computed column you'll be able to use such a column in your LINQ queries. For example:
var users = Database.Users.Where(u => u.FullName.ToLower().Contains("string"));
You won't get errors like "not supported in LINQ to Entities" because this property is really a part of your model object. All the heavy lifting occurs on the database side.
Of course you could place a FullName property in a partial class and use it.
public string FullName
{
get { return string.Format("{0} {1}", FirstName, LastName); }
}
In this case, you'll have to call .ToList() first ( Database.Users.ToList(); ) to be able to use this property in LINQ queries. .ToList() will hydrate/bring all your Users to memory. This is not desirable!
You can also try the FullName property implementation that's described here: Calculated Columns in Entity Framework Code First Migrations
In some scenarios I need a "wide" version of an entity with many properties (say FullCustomer) while in other scenarios it's enough with a "narrow" version with few properties (say MiniCustomer), how could I map these two entities, FullCustomer and MiniCustomer, to the same Customer table in the database? Furthermore, I need to be able to query and update both entities.
Thanks in advance for any advice or pointers!
PD. I'm using VS2010 RC and EF 4
For "efficiency", don't have two versions of the entity; just project onto "lite" POCOs:
var q = from e in Context.Entities
select new LitePoco
{
Id = e.Id,
EditThis = e.EditThis
};
No other columns will be returned.
Similarly for save:
var e = new MyEntity { Id = 123 };
Context.AttachTo("Entities", e);
// anything from here on gets saved
e.EditThis = "Edited";
Context.SaveChanges();
If you have a column that determines whether to treat the record as a FullCustomer or as MiniCustomer, then you can easily create a Table per Hierarchy inheritance model with FullCustomer inherited from MiniCustomer. Such approach is described in the Muhammad Mosa's blog post.
If you don't have this column you can update the model and database in order to add it.
However, there is an alternative approach. If the reason to have two entities for one table is the delay in the loading the numerous large properties in the FullCustomer object, than Table Splitting might be an option. Take a look at the Julie Lerman's blog post.
I would have noted that this problem is not present in ORMs like LINQ to SQL, due to deferred loading.