ASP.NET

Minimize a DropDownList's ViewState

Jeff Smith — Thu, 17 Apr 2008 16:21:16 GMT

Let's say you have a very large DropDownList with lots of values and text. We need to maintain ViewState in this DropDownList so that we can retrieve the selected value on a post back. Of course, this means that now the ViewState contains the data for every single value in the list, both values and text included. Even though the page itself may be fairly simple and lightweight, the result of having this simple DropDownList on the page is that the page size is quite large and the amount of data passed back and forth on a postback is very large as well.

If you have an efficient database, and/or if you are caching the data anyway, you might not mind re-loading the list items each time the page posts back to eliminate the need for the page itself to hold all of this ViewState data.

However, if you turn off ViewState on the DropDownList, you will notice that it now does not remember the selected value on post backs. The solution is very simple -- just manually set the DropDownList after re-loading it to the value from the HTML form post.

To do this, first we disable ViewState on the DropDownList (EnableViewState="False"). Then, instead of a typical PageLoad() method like this:

protected void Page_Load(object sender, EventArgs e)

{

if (!IsPostBack)

{

loadList();

// other stuff here

}

we would load the list every time the page posts back:

protected void Page_Load(object sender, EventArgs e)

{

loadList();

if (!IsPostBack)

{

// other stuff here

}

And, in that loadList() method, instead of simply doing this:

void loadList()

{

dlTest.DataSource = // get data from DB

dlTest.DataBind();

}

you also would check to see if it has a posted value:

void loadList()

{

dlTest.DataSource = // get data from DB

dlTest.DataBind();

string r = Request[dlTest.UniqueID];

if (r != null)

dlTest.SelectedValue = r;

}

That loads the DropDownList each time and ensures that the value set is what was posted back. Thus, the control will now "remember" the selected value on each postback, but without requiring any data stored in the ViewState at all.

It would also be easy to implement this logic in a control that inherits from DropDownList; say, a LightDropDownList. Techniques like this will of course work on other controls as well, such as a ListBox or a CheckedList.

With fast database connections and performance, as well as data caching, sometimes persisting data on the page is not the optimal way to go. Like always, there are different ways to skin a cat and sometimes simple little tweaks like this can have huge benefits on performance.

Update: See the comments for other options are that even easier/better. Also in the comments, Richard has provided a link to this excellent post on ViewState that I highly recommend checking out. It's long, but very informative and quite entertaining as well. Thanks for the great feedback.

Splitting a single DataTable into Parent/Child DataTables for Hierarchical Processing (e.g., nested ASP.NET Repeater controls)

Jeff Smith — Fri, 02 Nov 2007 16:16:21 GMT

In ASP.NET, we often would like to output "grouped" data on our web pages, like this:

Customer Product     Sales
-------- ---------- -----
ABC Foundation
         Product 1   $200
         Product 2   $437
         Product 3   $523

The XLZ Company
        Product 1   $240
        Product 2   $892
        Product 3   $395

The easiest way to do this is with nested Repeater controls; one for the outer group (Customers, this case), and within that Repeater's ItemTemplate we'd have another Repeater control for the details (Products).

To use nested repeaters, you would return two separate result sets from SQL:

A "Customers" result set, listing one row per Customer to display on the report
A "Products" result set, listing one row per Product to display.

You would put both of those results into a single DataSet as DataTables, and then create a relation between the two (on the CustomerID column). Now, in our DataSet, we have a parent-child relation and each row in the parent Customers DataTable will have related child rows in the Products DataTable.

Then, in ASP.NET, we create nested repeaters: the outer repeater is bound to the Customers DataTable, and the inner repeater gets bound for each Customer row to the child rows in the Products DataTable. There are lots of good examples detailing this technique here and here, so I won't get into specifics on that in this space.

However -- what if you already have a stored procedure that returns this data in a single result set? The nested Repeater controls won't do you much good, since we need two separate (but related) DataTables. Or, what if it is inefficient to return these results separately in SQL? For example, suppose we want to output only the products for customers that have a total sales of greater than $200 for a specified time period. We'd need to process the sales transactions table twice in SQL to generate the list of Customers separate from the list of Products. Thus, our SQL becomes twice as inefficient as it needs to be to use this technique.

To accommodate those possibilities, I recently wrote a simple function in C# that takes a single DataTable and creates a related parent DataTable in the same DataSet based on specified parameters. This is useful if you only have a single result set from SQL (or any other data source) and you'd like to break that data up into two separate parent-child DataTables in order to use nested repeaters or any other type of parent-child processing on the data.

As an example, if you start with a single DataTable like this:

Products:

CustomerID CustomerName    Product     Sales
---------- --------------- ---------- -----
1           ABC Foundation Product 1   $200
1           ABC Foundation Product 2   $437
1           ABC Foundation Product 3   $523
2         The XLZ Company Product 1   $240
2         The XLZ Company Product 2   $892
2         The XLZ Company Product 3   $395

We can pass that DataTable to the CreateParentTable() function and you would end up with two related DataTables in the DataSet, like this:

Customers:

CustomerID CustomerName
---------- ---------------
1           ABC Foundation
2         The XLZ Company

Products:

CustomerID Product     Sales
---------- ---------- -----
1           Product 1   $200
1           Product 2   $437
1           Product 3   $523
2         Product 1   $240
2         Product 2   $892
2         Product 3   $395

Then we can simply bind the outer Repeater to the Customers DataTable, and then bind the inner Repeater to a call to each DataRow's GetChildRows() method to get the related products. All from a single SQL result set.

Also, notice that the function removes the CustomerName column from the Products DataTable, but leaves the CustomerID column for the relation.

Here's the function:

/// <summary>
///   Creates a parent DataTable within the DataSet using distinct rows from
///   an existing "source" DataTable, based on the column(s) specified.
///   The source table then becomes the "child" table of the newly created
///   parent. A DataRelation is also created between the parent table and the
///   child table, using the column(s) specified.
/// </summary>
/// <param name="sourceTable">
///    The source DataTable, which must be within a DataSet.
///    This source table will become the "child" table.
/// </param>
/// <param name="parentTableName">
///    This name will be assigned to the parent table once it is created.
/// </param>
/// <param name="relationColumns">
///    Specify the columns used to relate the parent table to the child table.
/// </param>
/// <param name="additionalColumns">
///    Any additional column(s) in the source table that will be extracted to the
///    parent table. These columns will be removed from the source table.
/// </param>
/// <param name="relationName">
///    The name of the relation that will be created between the parent and
///    the child table.
/// </param>
///
public static void AddParentTable(DataTable sourceTable, string parentTableName,
     string[] relationColumns, string[] additionalColumns, string relationName)
{
    DataSet dataSet = sourceTable.DataSet;

    if (dataSet == null)
    {
        throw new Exception("The source DataTable must be contained in a DataSet");
    }

    // generate the set of columns to use to create the Parent table:
    string[] cols = new string[relationColumns.Length+additionalColumns.Length];
    relationColumns.CopyTo(cols,0);
    additionalColumns.CopyTo(cols,relationColumns.Length);

    // create the parent table, copying unique rows from the Child table:
    DataTable parent = sourceTable.DefaultView.ToTable(parentTableName, true, cols);

    // add the parent table to the DataSet:
    dataSet.Tables.Add(parent);

    // remove the additional columns from the child table that were
    // copied to the parent table:
    foreach (string s in additionalColumns)
        sourceTable.Columns.Remove(s);

    // create the relation between the new parent table and the child table:
    DataColumn[] parentColumns = new DataColumn[relationColumns.Length];
    DataColumn[] childColumns = new DataColumn[relationColumns.Length];

    for (int i=0; i< relationColumns.Length;i++)
    {
        parentColumns[i] = parent.Columns[relationColumns[i]];
        childColumns[i] = sourceTable.Columns[relationColumns[i]];
    }

    // And, finally, add the relation to the parent table:
    parent.ChildRelations.Add(relationName, parentColumns, childColumns);
}

The parameters are all explained in the XML documentation. Feel free to make modifications or overloads of this function. Some good overloads might be one that accepts a single relation column name, or that accepts a parameter that determines whether or not columns are removed from the child table.

Using our example, we'd call it like this:

SqlConnection cn = new SqlConnection(<... your connection string ...>)
SqlCommand cm = new SqlCommand(<... the name of the stored proc ...>, cn);
cm.CommandType= CommandType.StoredProcedure;
cn.Open();

SqlDataAdapter da = new SqlDataAdapter(cm);
DataSet ds = new DataSet();
da.Fill(ds, "Products");

CreateParentTable(ds.Tables["Products"], "Customers", new string[] {"CustomerID"},
new string[] {"CustomerName"}, "CustomerProducts")

After that is executed, the DataSet now contains an additional "Customers" table, and a relation called "CustomerProducts" to the "Products" table. The relation is on "CustomerID", and the "Customers" table also includes the "CustomerName" column.

Thus, if we had nested repeaters in our ASP.NET code like this:

<table>
    <tr>
        <th>Customer</th>
       <th>Product</th>
       <th>Sales</th>
    </tr>
<asp:Repeater runat="server" ID="rpt1">
    <ItemTemplate>
       <tr>
            <td colspan="3"><%# ((System.Data.DataRowView) Container.DataItem)["CustomerName"] %></td>
       </tr>
       <asp:Repeater runat="server" ID="rpt2"
        DataSource='<%# ((System.Data.DataRowView) Container.DataItem).Row.GetChildRows("CustomerProducts") %>'>
            <ItemTemplate>
            <tr>
                <td></td>
                <td> <%# ((System.Data.DataRow) Container.DataItem)["Product"] %></td>
                <td> <%# ((System.Data.DataRow) Container.DataItem)["Sales"] %></td>
            </tr>
        </ItemTemplate>
       </asp:Repeater>
    </ItemTemplate>
</asp:Repeater>
</table>

we can simply assign rpt1's DataSource to our DataSet, set its DataMember as "Customers", call DataBind(), and we are good to go:

rpt1.DataSource = ds;
rpt1.DataMember = "Customers";
rpt1.DataBind();

A couple of more notes:

The outer Repeater's DataItems are DataRowView objects, but the inner Repeater's DataItems are DataRows. This is because we called the DataRowView's DataRow's GetChildRows() method, and not the DataRowView's CreateChildView() method. I have found that this provides much better performance. For small results, you may wish to call CreateChildView().
Instead of databinding in the HTML markup, you may wish to bind the inner Repeaters during the outer Repeater's DataBinding() event. This keeps your HTML markup a little cleaner and shorter.
This function only works in .NET 2.0 or above, since it uses ToTable() method of the DataRowView class.

For more on nested repeaters, see:

Note that all of those example use two separate SQL result sets. Using the function provided, we can do the same with a single result.

see also:

Some HTML / ASP.NET Thoughts ...

Jeff Smith — Wed, 17 Oct 2007 15:13:10 GMT

On a particular real estate website, we have a "Property Summary" section that contains each property's name, the address, a phone number (if it exists), and a contact email address (if it exists).

The information is data bound to properties in the page's code-behind, and the ASP.NET code basically looks like this:

Because lots of these elements are optional, all of these properties have all been written to work like this in the code-behind:

Protected Readonly Property AddressLine1 as String
Get
     If _AddressLine1 = "" Then
      Return ""
    Else
      Return _AddressLine1 + "<br>"
    End if
End Get
End Property

It was written this way so that there will not be extra empty lines where the data is missing, and there will be a line break if data exists. Typically, AddressLine2 and AddressLine3 are blank, but they may be present. The Email property, since it is a link, is even worse:

Protected Readonly Property Email as String
Get
     If _Email = "" Then
      Return ""
    Else
      Return String.Format("<a href='mailto:{0}'>{0}</a><br>", _Email)
    End if
End Get
End Property

That a lot of HTML in the code-behind that ideally we'd have in the markup. My first instinct to make this a little cleaner/simpler was to create a function like this:

Protected Function CheckBR(TextToCheck as string) as String
If Text.Trim() = "" Then
Return ""
Else
Return "<br>"
End if
End Function

That way, I could remove the empty check and the append of the <BR> tag in my properties, and then use my function on the Page like this:

That way, all optional lines will only have breaks if they exist; only non-optional lines will have <br> tags specified. This still seemed sloppy. I thought adding "runat=server" to the "<br>" tags and then specifying the Visible property like this:

but that really seemed like overkill and didn't appear to make things any cleaner. Isn't there an easier way? I wondered if I should create a custom ASP.NET "conditional line break" control ...

Then I remembered how browsers render empty tags: Even if the tag is a block element, and the tag is empty, nothing is rendered -- including the line break! For example, this:

<div>Hello</div>
<div></div>
<div>Bye</div>

displays as:

Hello
Bye

That is because the middle <div> contains no text (not even a single space) or any other content that is visible. Thus, all we need to do is use <div> tags, not <br> tags, for our line breaks, like this:

Notice that our Email property can simply return the email address and not worry about creating a link, and all of our properties can simply return raw data. We always output the <a> tag without the need to check if the email address is present; if the containing text is empty, neither the link nor the <div> will render in the browser. That is,

<div>Hello</div>
<div><a href="someurl"></a></div>
<div>Bye</div>

still displays as:

Hello
Bye

in the browser.

This is a little off topic and has nothing to do with SQL Server directly, but it may be a handy tip or reminder for some. It's nice to get rid of the embedded HTML in the code behind and to eliminate some extra code. This same concept also applies to <p> tags, though in this case we are not using them because the spacing would be too much. (You could alter this via CSS, of course).

UPDATE: In the comments, JD suggests an alternative which I like better. The only negative is that html tags are being "hidden" in your code-behind, and you'd have to adjust your function (or create a new one) to handle hyperlinks or more complicated output.

But, if you can and would like to create additional functions to help with the formatting, that is a good option. If you cannot create additional functions or want to eliminate as much code-behind as possible, then the "empty block element" trick can be useful, especially if you already have the tag on your page.

For example, instead of using server-side logic

or using a function that wraps non-blank text in <p> tags:

<%# PrintAsParagraph(SomeText) %>

you can simply write:

By eliminating the spacing, the paragraph and all of the associated spacing will not display at all if SomeText is blank.

Thanks for the input, JD!

see also:

Creating CSV strings in SQL: Should Concatenation and Formatting Be Done at the Database Layer?

Jeff Smith — Tue, 09 Oct 2007 19:02:57 GMT

A question I see very often in the SQLTeam forums is how to return data in a summarized form by concatenating a list of values into a single CSV column. This can be done fairly easily in T-SQL, but as the formatting and concatenation requirements becomes more elaborate, be sure to ask yourself: Am I forcing presentation code into the database layer? read more...

Using LINQ with SQL (link)

Jeff Smith — Fri, 13 Jul 2007 20:27:44 GMT

There's a great series of posts over at Scott Guthrie's Blog covering LINQ, a new feature in the upcoming version of Visual Studio ("Orcas"). Check it out; I have not had a chance to play around with it yet, but it certainly looks very interesting. The articles are very well done and explain the concept very clearly with lots of examples.

From the article:

The above language features help make querying data a first class programming concept. We call this overall querying programming model "LINQ" - which stands for .NET Language Integrated Query.

Developers can use LINQ with any data source. They can express efficient query behavior in their programming language of choice, optionally transform/shape data query results into whatever format they want, and then easily manipulate the results. LINQ-enabled languages can provide full type-safety and compile-time checking of query expressions, and development tools can provide full intellisense, debugging, and rich refactoring support when writing LINQ code.

Link: Using LINQ to SQL (Part 1)

ASP.NET 1.1 -- Appsettings in Web.config

Jeff Smith — Wed, 28 Mar 2007 16:09:16 GMT

It's great to be able to put settings in the Web.Config file for my ASP.NET projects. The problem for me, though, is that when I use System.Configuration.ConfigurationSettings.AppSettings(name) to return a setting that doesn't exist in the file ...

read more

Minimizing the ViewState for an ASP.NET 1.1 DataGrid

Jeff Smith — Wed, 12 Jul 2006 02:22:00 GMT

By default, the ViewState for ASP.NET DataGrids can be quite large, as it normally stores enough information to recreate the grid completely after a postback. Often, I have found that I need the grid to display a list of items with only paging, sorting, and some buttons that let you delete or edit (via another page) individual items.

read more...