I have an Stored Procedure which may return some unpredictable rows and columns, based on some business logic written in my SP. That is for sure that it will return only one set of Result Set data from this SP.
Whatever the result my SP returns, it should be reflected into my GridView. Due to some framework restrictions, I can not use ADO.Net DataSets/DataTables.
I am using Entity Framework 4.0 for my project and I want some solution to bind my GridView with dynamic nature of DataSource returned by my Stored procedure.
I think, this is very common problem which many developer has encountered in such type of situation.
Is there anyone who have found some work around to achieve the goal within the boundary line of Entity Framework?
Note: Keep in mind that, I don't want to use ADO.net DataSet or DataTable.
I think you are fetching data from proc and stored in List like that.
List<HRDocumentCheckList> searchJoiningDoc = GetJoiningDocumentForEdit(ddlCategory.SelectedValue.ToInt32(), false).ToList();
gvJoiningDocumentTemplate.DataSource = searchJoiningDoc;
gvJoiningDocumentTemplate.DataBind();
Just bind the gridview and set the autogenrated column is false
Hope it will helps you
Related
Using EF6 Framework4.5 – Creating my first n-tier app and first EF experience. I have CRUD working but one issue that I have a work-a-around but don’t like it. There must be a better way.
When data object is returned from my UI layer to the DAL layer, it has been detached, so I flag EntityState as “Modified.” But then it updates all columns in the db. Values that were not loaded in the form view (and not submitted) obviously are null and updated to such in the db.
1) My first solution does work:
Store the object in session in the UI layer and loop through the object updating edited values when the form is submitted. Thus, original values are passed back unchanged and updated to original values. I don’t think this would be best practice though.
2) The solution I think I want:
I am looking for a helper function in the DAL layer to loop through all values in the returned object and flag only non-null values as “IsModified” before calling SaveChanges.
I have found examples in C# on how to check for changed value but not null. (I am still a vb guy anyway. Don't hate.)
A) Is solution #2 a good way to do this?
B) Has anyone a piece of good to help me?
Thank you.
BTW, this is my best stab at it so far: (Errors on “CurrentValues”)
Public Overridable Function MarkEntriesModified(entity As Object)
Dim dbEntityEntry = DbContext.Entry(entity)
'Ensure only non-null values are inserted
For Each [property] In dbEntityEntry.CurrentValues.PropertyNames
If Not IsDBNull(dbEntityEntry.CurrentValues.GetValue(Of Object)([property])) Then
dbEntityEntry.[Property]([property]).IsModified = True
End If
Next
Return entity
Try this architecture. So if you are using EF then I suppose you have edmx updated and correctly representing your database objects.
eg: Say you wan to update Customer data in customer table
Create a Customer class.
when you extract a particular customer, get an instance of the
customer created.
pass this instance to the UI
and pass the instance back to Business layer to save
this way you don't loose anything in between.
some sample code
I'm new to infragistics. I have a database and a datalayer with entity framework and linq. Now I want to get the data to an Infragisticscontrol, let's use a UltraCombo. I have not problem to bind the data to the control. My problem is that all properties from the linqquery is displayed.
As far as I can see there are two options
1) Create a data schema manually. In this way there is much effort put in creating the schema and when I refactor something then the schemas of all controls must be updated.
2) Creating a data schema automatically.
I played a bit with the secand case but can'T find an option how to create the data schema automatically but binding the data manually. I had one case where I bound it to a model of the entity framework and deleted the datasource later from the project. In this case it worked but I don't think that this is the right way to use it.
Can somebody tell me how to do this or what's the best practice?
I found a solution in the Infragistics forum below. Here's the link: http://blogs.infragistics.com/forums/p/24379/89509.aspx
How to keep custom paging for dynamic result sets ? (i.e) based on 10 Dropdowns selection my stored procedure will Dynamically generates resultset,but it populates million records.
Row statically know Record count,cusom paging is efficient,but how to achieve it for dynamically grown result set?
Problem
I have to bind generic List to GridView,Columns are fixed,but the number of rows retuened are unknown,but without custom paging my GridView took 30 minutes to populate the result.
If possible, you should use LINQ, as the extensible operations make for easy paging.
Essentially, you would specify an ObjectDataSource or LinqDataSource for your GridView.
You would then have an IQueryable<T> method which accepts a starting position and number of rows to retrieve.
Then you make use of Skip() and Take() to achieve simple paging.
Here's a very good article on doing that.
Remember that Skip() and Take() are methods exposed to any class which implements IEnumerable. So even though the above article uses LINQ-SQL for their data repository, as long as your own DAL exposes a collection of type IEnumerable, you can use the Skip and Take pattern.
Hope that helps.
An easy way to do this server side would be to use LINQ. Took at the .Take() method.
Often I need to combine data from multiple tables and display the result in a GridView control.
I can write a Linq query inline in the Page_load event, return an anonymous type that combines all the fields that I need, and databind the result to the GridView control.
Problem: I use 'helper methods' as described by Scott Guthrie on his blog. Such a helper method cannot return an anonymous type. The query would have to be inline for this approach.
I can write a database view that returns the data that I need, and write a helper method with a query against this (new and known) type that it returns.
Problem: I will need a lot of views in my database schema, and I will introduce a lot of redundant aspects of my data. I also lose some of the advantage of using Linq - removing all business logic from the database.
I would like to take an approach that lets me keep the Linq queries in helper methods, yet allows me to access all the attributes that I need on the grid in their respective databinding expressions. Can this be done?
I asked the wrong question, as I frequently do. What prompted me to look into anonymous types was an apparent limitation of the GridView - my inability to use a databinding expression in an <asp:BoundField> (the DataField parameter only accepts column names of the table that the Linq query pulls in).
Turns out that in a TemplateField it is possible to use Eval and access members of the Linq data item, and Linq takes care of the query for me.
In other words, I can keep the query in my helper method, have it return a primary database table type (e.g. Account), and I bind the Accounts to the GridView.
In the databinding expressions I can access data members of the Account objects that reside in other tables, without having to explicitly pull them in in the query. Perfect.
I don't know if there is a viable way to achieve this using anonymous types. But I have a suggestion that will work in WinForms, but I am not sure about ASP.NET.
What you need is a type with properties where neither the number of properties, nor the types and names of the properties are known at compile time. One way to create such a thing is ICustomTypeDescriptor.
You have to create a type implementing this interface with an private backing store of objects backing the properties returned by the query for one row from the query. Then you implement GetProperties() to return one PropertyDescriptor per column and PropertyDescriptor.GetValue() and PropertyDescriptor.SetValue() to access the backing array.
By implementing PropertyDescriptor.Name you will get the correct column name; this will probably require another backing store storing the property names. And there is a lot more to implement, but in the end your new type will behave almost like a normal type - and now the if - if the control you are binding to knows about and uses ICustomTypeDescriptor.
UPDATE
I just found an bit of text stating that ASP.NET data binding knows and uses ICustomTypeDescriptor.
Scott's earlier post in the series talks about shaping the result set before inserting into a grid:
Part 3 - Querying our Database
Scroll down to "Shaping our Query Results".
I recently began working on a project which has many gridviews on a single page. During creation of a new record, the user needs to be able to add/remove/edit these gridviews and then save to the database at the end. The problem with this obviously is that there is no datasource to bind the data too until after its written to the database.
This data represents a 1..* relationship, which is why the gridview data cannot be written to the database until the parent record has been created first.
The best way I have found so far to solve this is to use viewstate. This solution however does not seem ideal to me. I am also forced to manually create the gridview functionality with OnDeleting, OnUpdating, etc so that I can manage the binding of the viewstate with the gridview.
Does anyone have any suggestions on a better way to manage this situation, it seems like it would be a common thing?
UPDATE:
Keep in mind this data needs to be around throughout postbacks.
Use a DataSet as an intermediate connection to your data source. Fill the DataSet with your data and then bind your GridView to the DataSet setting the GridView DataMember to the name of the table it is supposed to bind to.
As the user updates tables it will add/modify records in the DataTables in the DataSet. When the user is done editing and clicks "Save" your code can then update the database from the datasets, either automatically using a DataAdapter, or manually looking at the RowState of the rows in the DataTables.
Use a DataAdapter and a Dataset. Invoke the fillschema method in the adapter to create de metadata (cols, constraints, relations, etc) in the dataset. bind the data tables created to the different grid views. update manually cheking each row rowstate on each table or call the adapter's update method to do it automatically. If you do it automatically you need to define commands for insert, delete, and update in the adapter.