Jeff Papiez - SQL Server Test Developer : ASP.NET 2.0

Databound List Boxes

jpapiez — Wed, 21 Jul 2004 23:27:00 GMT

This one had me stumped for a little while until I was kicked in the right direction.

The Problem

You have two tables, Address and State. Address contains an attribute StateId, which is a primary key in the State table. You create a GridView to allow users to edit the address records. But, rather than displaying the StateId, you want to display a DropdDwnList that's populated from the State table. You don't want to have to do an extraordinary amount of coding to make this work, and you don't have the resources to buy an 3rd party component.

The Solution

Version 2.0 of the .NET Framework has some nifty new data-binding options. And this I just came across today. The ASP.NET team created a Quickstart tutorial on this databinding method, so I'll paste the important parts here. What we have is a typical GridView (with only one template column). But what you should notice is that the DropDownList is bound to two different sources! The SelectedValue is bound to the corresponding row in the GridView (from SqlDataSource1) whereas the list itself is populated from SqlDataSource2.

<asp:GridView ID="GridView1" AllowSorting="True" AllowPaging="True" Runat="server"
        DataSourceID="SqlDataSource1" AutoGenerateEditButton="True" DataKeyNames="au_id"
        AutoGenerateColumns="False">
  <Columns>
    <asp:TemplateField SortExpression="state" HeaderText="state">
      <EditItemTemplate>
        <asp:DropDownList ID="DropDownList2" Runat="server" DataTextField="state"
             DataSourceID="SqlDataSource2" SelectedValue='<%# Bind("state") %>'
            DataValueField="state" />
      </EditItemTemplate>
      <ItemTemplate>
       <asp:Label ID="Label1" Runat="server" Text='<%# Eval("state") %>' />
      </ItemTemplate>
    </asp:TemplateField>
</asp:GridView>
<asp:SqlDataSource ID="SqlDataSource1" Runat="server" SelectCommand="SELECT [au_id],
      [au_lname], [au_fname], [phone], [address], [city], [state], [zip], [contract]
    FROM [authors] WHERE [state] = @state"
   UpdateCommand="UPDATE [authors] SET [au_lname] = @au_lname, [au_fname] = @au_fname,
      [phone] = @phone, [address] = @address, [city] = @city, [state] = @state,
      [zip] = @zip, [contract] = @contract WHERE [au_id] = @au_id"
   ConnectionString="<%$ ConnectionStrings:Pubs %>">
<SelectParameters>
    <asp:ControlParameter Name="state" ControlID="DropDownList1" />
  </SelectParameters>
</asp:SqlDataSource>
<asp:SqlDataSource ID="SqlDataSource2" Runat="server" SelectCommand="SELECT DISTINCT [state]
     FROM [authors]"
     ConnectionString="<%$ ConnectionStrings:Pubs %>" />

The full source for this sample, in both C# and VB.NET can be in the Beta QuickStart tutorials (http://beta.asp.net/quickstart/aspnet/). Click on Performing Data Access, then scroll down to the Data Binding in Templates tutorial.

I'm starting to realize there's much to learn about new changes coming down the pike with the next version of the .NET Framework. Time to get cracking!

How do we Integrate?

jpapiez — Wed, 21 Jul 2004 20:56:00 GMT

Some background is probably in order. I'm a Software Tester here at Microsoft. I work in the Integration Test Team, Release Release Services, SQL Server. One of my new jobs is to look at how our products integrate. Currently I'm investigating SQL Server and Visual Studio 2005.

My question to you is this:

If you've had the chance to try out Visual Studio 2005 Beta 1 (or earlier versions), what has been your experience with it's integration with SQL Server? What works well? What doesn't? What can we do to improve the integration between our two products?

If you haven't yet tried Visual Studio 2005 or SQL Server 2005, no worries. I'll take your comments on previous versions of Visual Studio .NET and SQL Server.

If you are up to it send feedback to this post, or reply to me directly: jpapiez@microsoft.com (no spam please :)

New Databinding in ASP.NET 2.0

jpapiez — Mon, 12 Jul 2004 23:50:00 GMT

First off, my hat's off to the ASP.NET team for some very cool new controls. I have been developing web content, on and off, for quite some time (let's just say a long time). Sometimes I really get tired of coding the same thing over, and over, and over, and over again. Hm.. that's a mistatement. Not sometimes, ALL THE TIME!

It's not terribly often that I write an application that doesn't, in some way, inteact with a database. It's very tedious to have to write the same bit of code to select/insert/update/delete, then to present that data to the client. But wait, there's more. If I'm doing more than just simple presentation, ie. I expect the user to be able to edit the code, then I have a whole lot more work to do to get that data back to the database.

For the first part of the problem I've been working on a tool set that streamlines the process of generating the data access tier. I point the tool at the database and it generates me a set of c# classes and stored procedures for doing the basic set of tasks. There's still much work to be done, but for simple project where I want to get something out quickly it works fairly well.

For the second problem, I only have to look as far as Visual Studio 2005 Beta 1. Enter the new data bound controls: FormView, DetailsView, GridView, and the new *DataSource objects. These are truely a godsend. I have spent the last few hours trying to get an understanding of how these objects work together and am quite suprised at how easy they are to use and how little (no) code there is to write!

First Step in Databinding - GridView

I started off my discovery process by dropping an ObjectDataSource control on a new WebForm. I was going to use a shared library from another project to test this out, so I had to manually enter the type name in the control properties. Even after setting a reference to the library the “Configure Data Source” wizard wouldn't allow me to select the appropriate class. Oh well, no biggie. I can enter this manually. Once that was done I set the SelectMethod to the method on my class that retrieves a list of object so I can choose which instance to edit. Then I dropped a GridView onto my form, bound it to the ObjectDataSource, pressed F5, and what do you know.. it worked! Ok, so I might have ommitted a few steps (like setting up the connecting string in my web.config), but that was pretty much it. I didn't have to write a single line of code, though I did spend some time mucking with the various styles until I found one that was somewhat appealing.

Two-Way Data-Binding?

So far, so good. Lets see how easy it is for two-way data binding. I will admit that this one gave me a problem, but after slowing down a bit and reading through a walk through, I was able to get it to work. In the GridView, the first column contains a link button that will link to a second page. I guess it didn't have to, but that's what I did, so bear with me.

The second page contains the ObjectDataSource configured to get a single instance of my class. I retrieve the primary key off the query string and use that as a SelectParam on the ObjectDataSource. According to the docs, your class can contain an update method where you supply all the fields as arguements to the update method, or, as my object has, an update method that takes an instance of the class. In the later case, you must also provide the type name of the class to the DataObjectTypeName property on the ObjectDataSource control.

Now, here's where it gets cool. I added a FormView control to the page, and set the datasource to the ObjectDataSource control. This automagically created item and editItem fields for each property that's exposed by my class. I switched the designer to the source view to edit the names of the Edit text boxes to something a little more descriptive. Then I had to add some buttons. In the Item template, I added a button with CommandName='edit'. Switching to the EditItem template, I add two more buttons, one with CommandName='update', the other with CommandName='cancel'. OK, that's all I need to do for configuring the FormView control.

Back to the ObjectDataSource. To finish up here, I had to add UpdateParams, one for each property on the object. Once that was done I was ready to test. I wish I could say that it came off just as I wrote, but it did take a bit of trial and error. All the samples I came across took the easy way out, used the SqlDataSource, which seems far easier than to use custom business objects. But now that I've got it all figured out I'll be working on a short tutorial to illustrate this entire process.

In Conclusion...

It really is pretty easy, once getting past a few initial hurdles, and again, a big THANK YOU to the ASP.NET team for making me much more productive. Now I can concentrate on the more interesting and exciting things, not that writing web plumbing isn't interesting and exciting, just not something I want to spend the bulk of my time on. :)