This was one of the hardest decisions we had to make.  We know this is a very intuitive way to work.  I’ve got my database, and I want it on my form (period).

Background

First, lets look at what we had in 2002, 2003.  In 2003 you could drag from Server Explorer to your form, but we didn’t give you textboxes and labels.  We gave you an untyped, configured DataAdapter

• With the untyped, configured DataAdapter on the form, you then had to right click and choose Create DataSet.

• Then you had to make sure the [Create DataSet on my Form] was checked.

• You had to choose to create a new dataset, or merge with an existing one.  And of course the DataAdapter was named SqlDataAdapter5 and the DatSet was named DataSet3.  Which was which…?

• Now, you still don’t have data bound controls.  You now have to drag controls from the toolbox (both a data entry control such as a textbox and a label).  You have to name them…

• And then, you’re still not done.  You have to navigate through the property grid, expand the DataBindings section and select the DataSet and Column.  DataSet3, DataSet2… ?

Whidbey

So, in comes Whidbey features where we now can create controls, labels, name them, and databind them.  See the Sept/October issue of Code-Magazine.com for my article on Drag Once DataBinding.  Note: you do need to have a subscription to view the whole article, but hey, code is a great magazine J  Once an article is two months old, they open it up to the public…

Here’s the problem

In order to give a complete experience we’re creating typed DataSets and Typed DataAdapters that are shared throughout the project. 

Here’s the scenario:

• Brand new project

• You create a connection to your database in Server Explorer

• You then drag the Id and Name from the Customers table to Form1

• You run the form and life is good.

• You then create Form2 and all the columns and create a DataGridView

• You press F5 and life seems good except you really don’t want all 50,000 customers loaded into your form.   So you change the default query on Form2 to load only those customers with a particular name WHERE Name LIKE @name.

• Depending on where you’ve done this, you will break Form1 as Form1 wasn’t expecting to provide @name as a parameter.  Form2 had additional columns which are now part of the schema of Form1 as well.

When you dragged the columns from Server Explorer to your form, behind the scenes we created a Typed DataSet and a Typed DataAdapter.  We then instance these on the form and databind controls to them.  So far, so good. 

When you dragged additional columns to Form2, we have a choice. 

• We could either create a 2^nd dataset named NorthwindDataSet1 and thus pollute your project with a bunch of DataSets each time you drag to the form.

• Or we could do what appears to be the smarter thing and merge the CustomerDataTable from Form1 with that of Form2.  Of course we’d merge the queries as well.  The net affect of this is we’ve actually changed what Form1 is working with.  It now has additional columns, and the query may be changed as well.  Would developers realize we were changing the classes that were instanced on other forms?  If they didn’t know this at first, what would they think when they figured this out.  Would this be helpful, or magical stuff that developers didn’t trust?

We experimented with some dialogs prompting the user to help us make the right decision about merging or creating new datasets or datatables, but the experience just wasn’t that great so we decided to just scale back.

The decision

So, ultimately, the entry points aren’t as intuitive.  …but we won’t mess with your perfectly working forms as you continue to build the project.  We should also keep in mind that while dragging from Server Explorer to the form is intuitive, it isn’t as feature rich.  For instance, developers don’t have a way to choose their default control; Textbox, DateTimePicker, DataGridView, ComboBox or even their own custom control. 

We did discuss merging much of the functionality from the Server Explorer with the Data Sources Window, but that would only be Database centric.  Where would you drag Objects from?  The most obvious is the class designer.  So, then we wind up with anarchy… I’m dragging from everywhere.  Gee, that actually sounds like what Microsoft would normally do. J  Seriously, that’s actually a great idea, but it just wasn’t feasible to get all this dev’d and tested and still ship the features we have.  It’s also not necessarily the “right” thing to do in the big picture.  If you look at the Data Sources Window, (especially when we ship Beta 2), compared to Server Explorer and the Class viewer, their each targeted at their basic usage design.  It was far more controlled to create a single collection of Data Sources that we could put all the Custom Controls and Relation semantic in.

Explaining the Data Sources Window and Server Explorer

Think of Server Explorer as all the Databases within your enterprise across multiple departments.  If your consultant, you might have Database connections for several customers. This list isn’t specific to a project…

Think of the Data Sources Window as what’s available within a specific project.  The “shape” of the DataSource may be different within your project then it exists at the source.  For instance it’s fairly common to join a table within a DataSet to list the Name as well as the foreign key id.  The Server explorer would only show that if you had a View or Sproc.

With the above complications of expectation compared to our typed DataSets and DataAdapters we felt it was better to be more explicit then magical.

The expectation is developers will pull in Data Sources from their enterprise into the Data Sources Window.  They may be database connections, queries, etc. from various different locations, object references from dll’s from my company, or web services from around the world.

The Data Sources Window will consolidate all the available Data Sources for the active project.

Steve Lasker

Program Manager

Data Design-Time for Client Apps

Blogs @ http://blogs.msdn.com/vbteam/category/4754.aspx