I have a simple asp FormView on my page, it's working fine and everything, but I noticed the page is somewhat slow to load up (2-3 seconds), when there's really no reason for it, it's such a simple page.
The problem is that the FormView is using a SqlDataSource, which is using a 'heavy' select statement, basically grabbing all the fields and all rows of a profile table (name, address, phone, etc.). I'm assuming the FormView needs to get all the records so the Paging works correctly, but is there a way to code it or an attribute I can use so it doesn't grab every row and column but just all the columns of the current NameId?
asp:
<asp:FormView ... DataSourceId="sdsNames" AllowPaging="True" DataKeyNames="NameId">
<EditItemTemplate>....</EditItemTemplate>
<InsertItemTemplate>...</InsertItemTemplate>
<ItemTemplate>
<asp:Label Text='<%# Eval("Name") %>'.../>
...
</ItemTemplate>
</asp:FormView>
<SqlDataSource ID="sdsNames" ... SelectCommand="SELECT * from tblNames">
I tried changing the SelectCommand to
SELECT * from tblNames where NameId=1
since the initial page should show the first entry. But then I lose the pagination, basically no way to view the next record.
What the Page looks like:
There is not a lot you can do to improve performance here. You're correct, the SqlDataSource does slow things down because it retrieves all of the rows from your table.
There are a couple of different approaches that come to my mind:
Remove fields from your query.
This is the simplest solution, though it might not apply to your situation. If there are fields you don't need to display / modify, remove them. So, rather than SELECT * FROM..., you have SELECT LName, FName, Mname FROM...
You're still getting every row, but at least there is less data in each row.
You could switch to the ObjectDataSource control.
I haven't used this control much, but MSDN says that it performs a little better, because it doesn't always have to retrieve every row:
Some data sources, such as the ObjectDataSource control, offer more
advanced paging capabilities. In these cases the FormView control
takes advantage of the data source's more advanced capabilities to
gain better performance and flexibility while paging. The number of
rows requested may vary depending on whether the data source supports
retrieving the total row count.
You could move away from the datasource controls.
This probably involves more complexity than what you're looking for, but it is the most flexible approach. You can retrieve just the columns and rows you want. You can create a PagerTemplate, and set the values when the FormView is databound. You would have to handle the PageIndexChanging and PageIndexChanged events to change the paging values yourself.
Related
Goal
What I need is to display a SQL DataTable to the user on a webpage through ASP.NET and allow them to select a number of rows very quickly and easily, and then hit any of a number of different buttons to signify different operations. The selected rows are to be sent off to be processed (generally sent to a webservice or similar through codebehind). This is a somewhat generic solution, as I will be using this same setup in many places - thus the data, and the available operations will be different.
The goal is to be able to know basically nothing about the data - that is for the user to understand. If this concept is already impossible (though I believe it is not), please let me know.
Pulling from T-SQL (SQL Server 2008 R2 or later).
Using ASP.NET to make aspx webpage. Codebehind is done in VB.NET, in both cases we're using 4.0
I'm fluent in C# and VC++, so if you can't easily translate your code, don't worry about that.
The problem
My problem has been creating a row selection process for the user which persists while sorting or paging the table, is quick for the user and relatively quick in response time, and which is reflected in the GridView's bound data (as this allows me to use a filter on a DataView to produce a DataTable for passing). If there's another way to know the selected rows then I'm all game so long as it is persistant and quick for the user.
I'm not debugging and I'm not having syntax issues (I do not believe) - I don't know how to proceed.
I don't necessarily need code as a solution - I need to understand if my metaphor is either bad practice, or simply uncommon and thus not well supported. In either case, what is an appropriate way to proceed? If nothing else, where do I look for a solution besides endless API and Tutorials?
My original plan
I wanted to use asp:GridView for binding the DataTable pulled from TSQL since I can auto-generate columns. This allows me to display data without needing to know what it is. I planned to add a specific boolean Column (left most) for storing the User's row selection. Then I can simply run a filter on the DataTable to produce a DataView, get the resulting DataTable from that DataView, and pass it down the chain.
All the columns except our specific selection one would be Read-Only. The user isn't editing data - their selecting records and view their selection side-by-side with the viewable relevant data.
Of note, I planned to check for name collision so our added Column doesn't collide with any existing Column in the DataTable - I'd rename it as needed using 'Select' followed by an integer produced by looping through, comparing my name to other columns, incrementing as needed.
I presumed that once I set this up, it would just handle itself: the user could click the resulting checkbox column cell's and it would change the data on the fly. The point of saving the selection was their selection persisted through sorting and paging for convenience (I save the GridView's DataSource and re-bind when necessary). It didn't really matter if the user refreshed the page and completely and lost their checkboxes - they would need to review any changes/new data, and they wouldn't need more then a brief moment to check off whatever they wanted.
This did not happen.
I found that AutoGenerateColumns does not produce checkboxes for boolean DataColumns. It produces text, so I end up with the word 'True' or 'False'.
I began looking for a way to get check boxes in the cells for a boolean DataColumn. I found that for the added boolean column, I could bind an asp:CheckBoxField to it using the attribute DataField. Of course, I have to figure out how to point it at a variable DataField...
<Columns>
<asp:CheckBoxField DataField="Select" HeaderText="Select"
ReadOnly="False" SortExpression="Select">
<ItemStyle HorizontalAlign="Center" />
</asp:CheckBoxField>
</Columns>
However, because a GridView is designed for Row-By-Row editing, all the resulting CheckBoxes are disabled and cannot be checked. This is because their containing row is not in Edit Mdoe. I do not want to enable Row-By-Row editing using a button or similar metaphor as the user often needs to check off several rows. More clicks is bad, and annoying. They should be focused soley on their data and making their selection, not worrying about remembering to enter and end edit mode. Also, the metaphor seems poorly placed here since the checkboxes are the -ONLY- editable data - and are not part of the represented data.
I could, of course, make a new class which inherits from GridView, overload the method which generates columns to produce checkboxes instead of text fields - but I felt there had to be a more straightforward path. Maybe this is the way to go? But maybe it would have the same editing issue as above - I'm not sure.
So, next I tried looking at using an asp:TemplateField as a column in my GridView. This TemplateField contains an asp:CheckBox who's Checked state is based on the underlying bound data value. The issue here is trying to make changing the check-state update that bound value. I would need some way of looking up a GridView value I could then use to find the same row in the DataTable. I've seen great examples using a Primary Key. While I could assume everyone keeps a Primary Key for any possible table, this might not be the case! I could further add a Primary Key myself, but now it looks like I would be adding and removing two columns before I pass a DataTable off to a WebService instead of just one. Again, I also would need to be able to assign a Column name which is dynamic to avoid collision.
<asp:TemplateField HeaderText="Select">
<ItemTemplate>
<asp:CheckBox runat="server" ID="CheckBox"
Checked="<%# DataBinder.Eval(Container.DataItem, "Select") %>"
AutoPostBack="true" OnCheckedChanged="SelectCheckBox_CheckChanged" />
</ItemTemplate>
</asp:TemplateField>
I stopped myself - This path is also fairly indirect. Surely there is a much cleaner, simpler way to do this. Is it uncommon for someone to display Read-Only data where records are selected to be submitted, in one fashion or another, for processing/updating/alteration?
Is my choice of GridView poor? I haven't yet found another good way to represent Table data.
I have several Gridviews and Repeaters bound to SqlDataSources using stored procedures. I am trying to implement sorting functionality into some of these but am having a hard time finding concrete instructions and/or examples of what is required on the SqlDataSource side to generate the ORDER BY's needed. Particularly, I do not understand the point of having a SortParameterName property in the SqlDataSource if all it does is manually connect to an ORDER BY clause in the stored procedure. Why define it as such if it is just another parameter in the SelectParameters list like any other, but just so happens to be connected to the ORDER BY clause? When I run the code example below, I am told there are too many arguments specified (obviously, the extra SortParams argument). Do I really need to alter my stored procedures and add "ORDER BY #SortParams" clauses to the end of the existing queries to make this work? I feel like I am missing something.
SqlDataSourceInLine.SelectParameters.Clear()
SqlDataSourceInLine.SelectCommandType = SqlDataSourceCommandType.StoredProcedure
SqlDataSourceInLine.SelectCommand = "ApproverGetApproved"
SqlDataSourceInLine.SelectParameters.Add("CompanyID", ConfigurationManager.AppSettings("Temp_CompanyID"))
SqlDataSourceInLine.SelectParameters.Add("SortParams", "EmpName DESC")
SqlDataSourceInLine.DataSourceMode = SqlDataSourceMode.DataSet
SqlDataSourceInLine.SortParameterName = "SortParams"
Dim dv As DataView = SqlDataSourceInLine.Select(DataSourceSelectArguments.Empty
Any clarification would be appreciated!
I was just trying to figure out how to use the SortParameterName and found this question. After doing some more search I think I have now found the correct answer.
Microsofts page Sorting Data with Data Source Controls says as follows (my emphasis):
The parameter identified by the SortParameterName property is passed to the ObjectDataSource control's SelectMethod or passed as part of the parameter collection to the SqlDataSource control's SelectCommand. The ObjectDataSource control can use the information passed to it in the sort parameter to return the data in sorted order. For the SqlDataSource control, you must supply the name of a stored procedure that can take the sort parameter and return the sorted data, because you cannot pass a parameter as part of an ORDER BY clause.
This indicates that the answer given by Icarus is not correct.
My conclusion is that when the SortParameterName property is set (in combination with an appropriate stored procedure) the Gridview will not do the sorting itself, but will let the datasource do a so called Custom Sorting, which for example would be the necessary way to sort if Custom Paging is used.
Update:
I have now used it in my own programming and confirmed that my conclusion was correct.
I've never used the SortParamter in the past, but what I gather from the documentation is that the purpose of this parameter is to allow you to get the results sorted in the way you want them in case the stored procedure does not do it already. Other than that, you don't need to use it for anything. A GridView whose datasource is of type SqlDataSource already implements sorting out of the box. You simply need to set the AllowSorting property to True and the SortExpression on every column.
Example:
<asp:GridView ID=" productsGridView" Runat="server"
DataSourceID="SqlproductDataSource" AutoGenerateColumns="False"
AllowSorting="True" >
<Columns>
<asp:BoundField HeaderText="Product"
DataField="ProductName" SortExpression="ProductName">
</asp:BoundField>
...
Nothing is required on the SqlDataSource. You need to implement the Sorting event for the Gridview and something else for the repeaters since they don't have sorting built in. What you could do (if you have small datasets coming back) is to use ViewState and store your DataTable of results and then utilize the DataView and the sorting capability of that, then bind the Repeaters/GridViews to the sorted DataView. You still have to keep track of the SortDirection and SortParameter within ViewState, regardless.
I have a scenario where I want to put four identical Gridviews on the same page. (They will be on different tabs in an Ajax TabControl.) They show the same source data, but there are four corresponding groups of source data in a common underlying table. So I want to show Group 1 on Tab 1, Group 2 on Tab 2, etc. These Gridviews contain complicated controls, so I would prefer to use the same data source for all of them to avoid unnecessary repetition. The Insert and Update commands are completely identical.
So in theory I could build the Select command in such a way that I could filter the data based on the GridView that is binding to the SQLDataSource. The problem is that if I use the same SQLDataSource for all the Gridviews, I cannot find a way to have each GridView tell the SQLDataSource which one is calling it. I am thinking maybe this is not possible, because the SQLDataSource binds first before it knows what is binding to it, but I'm not sure. Can anyone think of a way to do this?
You can change the parameter value dynamically using OnSelecting event of SQLDataSource. This can be done in server side code.
Create a property which holds your current gridview unique key, which is causing SQLDataSource to fetch data from SQL database.
Assign this property unique gridview key on DataBinding event of gridview.
Based on this property change the parameter in OnSelecting event of SQLDataSource.
Let me know if I am missing something.
Currently, I have a page that has a table that shows a varying level of information depending upon the logged in status of the requester. It is set up as a table with repeaters pulling from a data source.
Some examples of things that are different:
The Date of Birth column gives the exact DOB for those with a certain role, and the month of their birth for other users.
Last names are a hyperlink for those in a certain role, and just a regular literal for everyone else.
There is also an extra column in a table for those with a certain role.
Currently, I essentially have the entire page duplicated with minor tweaks inside the loginview control. This seems like a poor way to do business, but I'm not really sure of a cleaner way to do it with webforms. With MVC and Razor (which I am less experienced with), it seems like it would be fairly trivial to tweak the output with some conditionals in the view but it seems less intuitive in webforms.
Is there a better way to do this in webforms?
I've done similar implementations using a repeater, and have had success with the following approach:
Use the decorator pattern to add "display directives" to the object you'll bind to the repeater. In your example, I might add bool flags for ShowFullDob, ShowLastNameAsLink, and ShowColumnX (for your optional column).
When you retrieve your data to be displayed, convert the model objects to your new decorated model objects, and set the bool flags as appropriate for the current request.
This is the part that's a little counter-intuitive: in your repeater's ItemTemplate, render ALL the data, but use your bool flags to set the Visible attribute (see code sample below).
<ItemTemplate>
<td runat="server" Visible='<%# (bool)DataBinder.Eval(Container.DataItem, "ShowFullDob") %>'>construct full DOB here</td>
<td runat="server" Visible='<%# !((bool)DataBinder.Eval(Container.DataItem, "ShowFullDob")) %>'>construct just the birth month/year here</td>
</ItemTemplate>
Perhaps other SO'ers can suggest more elegant ways of implementing conditional elements within a repeater - if so, I'd love to hear them! However, even though it's a little ugly and heavy-handed, it gets the job done.
I have a .aspx search screen that displays the results of the search in an asp:GridView component. There can be up to approx 1000 records returned by the search. I want to implememt paging on the grid so that only 15 records are displayed at any one time and the user can page through the results.
I am retrieving the records by passing search parameters to a WCF service which returns a List of particular entity objects. I create a Datatable and insert one DataRow per entity object from the List. I then bind the grid view to the Datatable.
This is how my grid is defined in the .aspx page:
<asp:GridView ID="gridCat" runat="server" AutoGenerateColumns="False" DataKeyNames="CatalogueID"
HeaderStyle-CssClass="fieldHeading" RowStyle-CssClass="fieldContent"
AlternatingRowStyle-CssClass="alternateFieldContent" Width="100%"
AllowPaging="True" AllowSorting="True" AutoGenerateDeleteButton="True"
PageSize="15">
and I also have this method in the code behind (.aspx.vb file):
Sub GridPagingAction(ByVal sender As Object, ByVal e As GridViewPageEventArgs) Handles gridCat.PageIndexChanging
gridCat.PageIndex = e.NewPageIndex
gridCat.DataBind()
gridCat.Visible = True
End Sub
My problem is this: the first page is rendered correctly i.e. the first 15 records are displayed correctly. However, when I navigate to page 2 in the grid, the GridPagingAction method is hit on the server but nothing is displayed in the grid - it is just blank.
I think the reason this is happening is because the Datatable no longer exists on the server when the request for the second page hits the server - is that right? And the asp:GridView, when it is rendering the first page of results, only takes the first 15 records from the Datatble and sends them back to the browser. So when the request for the second page comes in the other records (i.e. records 16 - 1000) don't exist anywhere - is all that correct?
If so, what's the best solution - I can't see how to implement paging without having to do one of the following:
re-perform the search each time the user uses the paging option;
saving the search results on the Session after the first Search retrieving them each time the user uses the paging option;
manually inserting the Search results into ViewState and retrieving them each time the user uses the paging option.
Is there a better way to do this (or am I doing it wrong)? If not, which of the 3 options do you think is the best? I'm leaning towards option 2 as I don't think option 1 is performant and I don't want to be sending loads of unnecessary data back to the browser as per option 3.
All you said is correct. You could either use ViewState or the Session to keep hold of the data on client- or server-side, but if you really have that many records, it might be a good idea to only collect the data you actually need.
So if you want to show records 1 to 10, you perform a query against the database and only fetch those ten records. If you want to show the next ten, you perform another query with the according parameters.
This will improve your performance and memory usage significantly, IF calling your DB is not overly expensive.
This article might give you a start on how to do this:
http://dotnetslackers.com/articles/gridview/Optimized-Paging-and-Sorting-in-ASP-NET-GridView.aspx
If you want an easy solution without any additional efforts, I would query all the records on each postback (your option #1).
If you want the best performing solution with not much overhead, use the custom paging.