Things About Typed DataSet Generation I Never Noticed...

I have been thinking a lot about how Typed DataSets are generated and was spelunking through the code again when it got me thinking. The Typed DataSet generator doesn't really generate the code based on the .xsd, but on the DataSet. It simply loads the .xsd into a DataSet then interrogates the DataSet directly for everything (tables, columns, relationships, constraints). So if the Typed DataSet Designer cannot handle something (like relationships *without* constraints, see below), but the DataSet schema allows it...simply create the DataSet and save the .xsd file to see what it produces! This gets around some fundamental problems with the designer. It does require you start looking and understanding .xsd, but it is a useful skill to have anyway...right?

So my first relevation was how to add unconstrained relationships (no foreign key constraint, simply a way to navigate the data). Since the designer does not allow this, I looked at the .xsd and found that the DataSet handles this with a schema annotation:

<xs:schema>
  <xs:annotation>
    <xs:appinfo>
      <msdata:Relationship name="ta2t" 
        msdata:parent="titleauthor" 
        msdata:child="titles" 
        msdata:parentkey="title_id"
        msdata:childkey="title_id" />
    </xs:appinfo>
  </xs:annotation>
</xs:schema>

The five pieces of data in the msdata:Relationship element are the four pieces of data required when setting up a relationship. Pretty simple huh!

It makes me start to think of other DataSet allowable things that the Designer doesn't know about.

• Aug, 14, 2003, 12:00 AM |
• Add Comments
  
• Tag(s): DataSets, ADO.NET, .NET
  

ADO.NET's DataAdapters and Opened Connections

I have been reviewing a bunch of code that utilizes ADO.NET's DataAdapters. This code has been some samples that are on the Internet, some questions directly to http://wildermuth.com and others from DevelopMentor's .NET Mailing Lists. One thing I have noticed is that much of that code is opening the database connection before using the DataAdapter to fill a DataSet.

This does work, but there seems to be some confusion about how this should work. In fact, under the covers all DataAdapters open and close the database if it has not already been done. This is because the DataAdapter knows when to open and close the connection to the database to minimize the length of time that the precious resource (the connection) is actually open. This is what the code looks like that I've been reviewing:

// Create the DataSet
DataSet dataSet = new DataSet();

// Create the Connection
SqlConnection conn = new SqlConnection("...");

// Create the Command
SqlDataAdapter adapter = new SqlDataAdapter("...", conn);

// Open the Connection
conn.Open();

// Fill the DataSet
adapter.Fill(dataSet);

// Close the Connection
conn.Close();

In reality, you don't need to open the close the connection before using it with an adapter. If the connection is closed, it will open it and close it as soon as it is done with the connection. I would expected to see more code that looked like this:

// Create the DataSet
DataSet dataSet = new DataSet();

// Create the Connection
SqlConnection conn = new SqlConnection("...");

// Create the Command
SqlDataAdapter adapter = new SqlDataAdapter("...", conn);

// Fill the DataSet
adapter.Fill(dataSet);

There are times when you would want to open the connection first, but usually only if you are doing many small Fill()'s or Update()'s. In most cases, letting the DataAdapter handle the connection object's state is the right thing to do.

• Oct, 14, 2002, 12:00 AM |
• Add Comments
  
• Tag(s): ADO.NET, DataAdapter, Connections
  

Web Services and DataSets: Why the Bad Rap?

Why is everyone so down on using DataSets in .NET Web Services? Sure, I’ll admit that using DataSets directly as Web Service parameters are indeed a problem. But why throw the baby out with the bath water?

For the uninitiated, DataSets are a problem as Web Service parameters because XML that is automatically generated as the parameter is a DiffGram of the DataSet. Unfortunately DiffGrams are simply not interop-friendly. At the end of the day the obvious use of DataSets in .NET Web Services are simply a bad idea.

But if we deal with DataSets as XML instead of a class to be serialized we can actually achieve some real benefits. If you have experienced DataSets, you know that you can specify an .xsd as the schema of the DataSet. What that means is that you can deliver the contents of the DataSet with relevant schema as an XML document. Since the resulting XML document can refer to a specific schema, the consumers of the Web Service (whether they are using Java, WebSphere, or .NET) will receive a self-describing, strongly typed piece of information.

But how does this work? The trick is wrapping your DataSet in an XmlDataDocument. By specifying your Web Service method like so:

[WebMethod]
public XmlDocument GetAllTheData()
{
  return new XmlDataDocument(yourDataSet);
}

This works because the XmlDataDocument derives from XmlDocument so that the XmlSerializer serializes it as an XML document. Whether the 'yourDataSet' field is a TypedDataSet or just a DataSet with an .xsd specified for its schema, the Web Service will export it as vanilla XML that can be consumed by any number of clients.

• Oct, 10, 2002, 12:00 AM |
• Add Comments
  
• Tag(s): .NET, Web Services, DataSet, ADO.NET