GridView and DataSource Controls

Posted Friday, June 10, 2005 8:48 AM by C-Dog's .NET Tip of the Day
I really haven't talked about this control, because a lot of other stuff touches on it, but I think it is now time. As you know the existing DataGridcontrol is a big pile of dog crap. It gets you close to providing a grid, but it you want to do anything like editing, sorting, or paging, well have fun. The GridView makes our lives easier because it truly supports these things out of the box with very little code.
GridViews can be completely configured by using SmartTags. When you drop a GridView control into the IDE, a SmartTag is available which allows you to configure a DataSource. All data bindable controls now support the concept of binding to DataSource controls. These new controls make it extremely easy to bind a control to a stored procedure, object, or XML file. The controls that handle this are SqlDataSource, ObjectDataSource, and XmlDataSource.
In this article, I will start with the SqlDataSource. Although we rarely write code that connects directly to a SQL Server without a web service, knowing how to use this control will help you on your side projects when you are just trying to slap something together. The SmartTag will allow you to build an ad-hoc sql statement or specify a stored procedure to use. To use it, you start by specify a connection string to your SQL Server. If you haven't created one yet, the wizard will again allow you to create one. Using the connection string, it will query the database and see what tables are available as well as stored procedures.
That just takes care of a select statement etc (something to retrieve data). What makes the SqlDataSource control powerful is that it can also be used to seamlessly insert, update, and delete data. You can specify a SQL query or stored procedure for each. When you start using the advanced featured of the GridView or FormView control these will be used for automatic editing.
Once you specify a statement, you have to specify where the values to your stored procedure come from. These can be added at runtime if necessary, but that would require code. What's even better is that they can be configured through the wizard to automatically accept a value from a Cookie, Control, Form, Profile, QueryString, or Session. This allows a lot of flexibility in the datasource without ever having to write a line of code.
Do you want the data to be cached? No problem. Simply set EnableCaching to true. Then set a CacheDuration to the number of minutes, you want to cache for. It also supports SqlCacheDependencies for adavanced cache invalidation features provided by SQL Server 2005.
 <asp:SqlDataSource ID="MasterSqlDataSource" Runat="server" 
SelectCommand="GetErrorLogEntries" CacheDuration="60" EnableCaching="True" 
SelectCommandType="StoredProcedure">
 <SelectParameters>
 <asp:ControlParameter Name="StartDateTime" Type="DateTime" 

ControlID="StartDateTimeTextBox"
 PropertyName="Text"></asp:ControlParameter>
  <asp:ControlParameter Name="EndDateTime" Type="DateTime" 
ControlID="EndDateTimeTextBox"
   PropertyName="Text"></asp:ControlParameter>
    <asp:ControlParameter Name="ServerName" Type="String" 
ControlID="ServerNameDropDownList"
PropertyName="SelectedValue"></asp:ControlParameter>
      <asp:ControlParameter ConvertEmptyStringToNull="False" Name="SearchString" 
Type="String"
ControlID="SearchStringTextBox" 
PropertyName="Text"></asp:ControlParameter>
        </SelectParameters>
         </asp:SqlDataSource>
Here is an example of a SqlDataSource used in the Error Log Viewer. In this case it pulls the values it needs from the four textbox controls on the page.
I'll be covering DataSource controls and the GridView more over the next couple of days. If you want to examine some actual code in use, take a look at the Error Log application. It is in source control at $/Thrifty.NETv2.0b2/WebAdministration/Diagnostics.

Read the complete post at http://www.dotnettipoftheday.com/blog.aspx?id=112