I have been a fan of Typed DataSets since the PDC Beta of .NET.  I’ve been asked to detail my recent criticism of Table Adapters in the .NET 2.0 Typed DataSets. Here are the points that I am most concerned with:

I was having a chat with David Sceppa about TableAdapters recently when he mentioned that in the final VS 2005 bits, the TableAdapters will use timestamp fields for concurrency.  I told him flatly I didn't think it worked, but I was wrong.  If you create a Table in a Typed DataSet in VS 2005 and include the timestamp field in the select statement, it will use the timestamp field for concurrency.  Awesome!

In this assembly, the designer created an app.config and a Settings.setting object.  All sounded good.  So in my ASP.NET 2.0 project, I setup the connection string in the web.config and called it "MyConnection".  This all worked until I deployed it to a server, when all hell broke loose.  After deployment, my code that did *not* use Typed DataSets (mostly DataSources) worked fine with my new "MyConnection" connection string...but...

Url: http://www.devsource.com/article2/0,1895,183430...

In Visual Studio 2005, when you create a Typed DataSet, it automatically creates TableAdapters for you.  These are interesting objects that use a DataAdapter internally to make a more cohesive data access layer.  It will certainly help the RAD developers get started.  I am not so sure about how they will work long-term though. 

Url: http://jelle.druyts.net/PermaLink.aspx?guid=616...

In previous builds, the DataSet had a property on them that said whether they should clear the DataSet whenever it is Filled by a DataAdapter.  It seems to be missing in the latest builds.  I actually prefer this because the nature of DataSets (and often overlooked) is that successive DataAdapter.Fill's will allow a DataSet to grow incrementally.  New rows will be added, and existing rows will be updated (unless it is dirty, then you would get an exception). 

Url: http://www.devcow.com/weblogs/To+Use+DataSets+O...

I've spent most of the last week in Redmond seeing some new stuff and meeting up with old friends.  While I was here I scheduled some time to sit down with Steve Lasker of the Visual Basic/Visual Studio Team.  His team in in charge of the Typed DataSet in Whidbey. 

Url: http://msdn.microsoft.com/library/default.asp?u...

Url: http://www.lhotka.net/WeBlog/PermaLink.aspx?gui...

I've been spending some time lately reviewing how companies are doing data access in .NET.  When I look at how most of them have crufted up solutions, I am amazed.  The model that Microsoft supports seems so obvious to me, but I am neck deep in it.  I'd like to hear from my readers their specific experience with creating data access in .NET; with an eye to why or why not use COM+ for transactions; Typed DataSet or DataReaders; Business Objects or Messages.  I am trying to understand where the community is.

I always forget this blog this, but when I am doing a database project using Typed DataSets, I almost always use a Component Surface to build my DataAdapters interactively.  For example:

Url: http://www.lhotka.net/WeBlog/CommentView.aspx?g...

For some time now I've been pushing the idea of doing DataSet updates using DataAdapters that use a 1-to-1 relationship between DataAdapter and logical data elements (e.g. Tables or Stored Procedures usually).  This is especially true when you are dealing with related tables in DataSets (the sweet spot for DataSets IMHO).  I've continually forgotten to post this code that I use to do these updates.  The idea of this code is for the user to provide arrays of Tables and DataAdapters that imply the order of the updates.  For example

Recently I was talking with Rocky Lhotka and he said something interesting:

I've had time lately to think about the nature of data in development lately.  I've been talking with Rocky Lhotka and Michael Earls about it (as well as number of others) about the issues with dealing with data in applications. 

I got to play with an Itanium 2 Box at the PDC today. Instead of following their script, I did what I've wanted to do for months...creating a huge DataSet. They had an interesting setup. You used a Pentium 4 box to develop code and then Terminal Service'd into a sixteen-way Itanium 2 machine to run the code. The 64 bit JIT's the IL to 64 bit code from the same assembly that the 32 bit JIT did to create the 32 bit code.

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?

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 those who do not know yet, the XML integration with the DataSet is very powerful. Most of the integration is about filling and getting XML from your DataSet. But the XmlDataDocument is really cool. Simply by assigning the DataSet to the XmlDataDocument, you can work with the DataSet data either relationally (through the DataSet) or hierarchically (through the XmlDocument). So, next time you need to transform the DataSet data or just run an XPath query, assign your DataSet to an XmlDataDocument and watch the magic begin...