Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Reality check on DataSet schemas

I did a walkthrough[1] using the XML schemas for DataSets and thought they were pretty whiz-bang neato.  Then I tried it in an actual project and ran into so many limitations that I've written them off for now.  They started to remind me of the Data Environment in VB6 (i.e., looks cool at first, but ultimately isn't).

They don't create the SQL for insert, update, or delete statements, and I can't figure out how to pass parameters to stored procedures.

After a while playing with them, I decided it was faster to hand code my data handling than it was to learn the ins and outs of using them.

But I wanted to do a reality check.  Before I write these off completely, I wanted to find out if these limitations are real or do I just need to spend more time learning how to use them?

[1] Q/A at Shawn Wildermuth's "the ADO Guy":

Wednesday, March 10, 2004

um, can't the sqlcommandbuilder do all the SQL for you? it's been a while since i've done this, but you should not need to re-invent the wheel. especially if you let it build the dataset from a SQL database.

Thursday, March 11, 2004

Maybe you are looking in the wrong place? All that stuff is usually done in the Data Adapter, which can then be used to generate a typed DataSet using the appropriate wizard. I imagine one can do that part by hand as well.

Chris Altmann
Thursday, March 11, 2004

>>um, can't the sqlcommandbuilder do all the SQL for you

The SqlCommandBuilder will generate Insert, Update, and Delete SQL only for single table updates.  Once you add relations, you're on your own.

Also, when I said "hand code", I meant something like the following:

string myQry = "SELECT ...";
SqlDataAdapter sda = new SqlDataAdapter();
sda.SelectCommand = new SqlCommand(myQry, myConn);

DataSet ds = new DataSet();
sda.Fill(ds, myTableName);

So, unless I've missed something along my bumpy learning curve, I don't think I'm re-inventing the wheel here.  Also, as I said above, if the myQry SELECT statement was multi-table, using an SqlCommandBuilder would not generate the update statements automatically.

Did you guys look at the link above?  It basically shows how to do everything with drag and drop, setting a few properties, then writing 1 line of code.  It's pretty slick, but only seems useful for selects, not insert, updates, and deletes.

Friday, March 12, 2004

Try dragging a database table from the Server Explorer to any design surface. You will get a new DataAdapter with select, insert, update, delete logic for that table.

If you want or need to customize the sql of any of those four commands, you can use the 'Configure DataAdapter Wizard' (At the bottom on the Properties window for a DataAdapter).

There you can specify your own stored procedures/queries or have VisualStudio to generate them automatically.

I don't know if this was what you where looking for, but It is worth looking at.

.NET Developer
Sunday, March 14, 2004

Something else which may be worth looking at:

and its related MSI package,

Monday, March 22, 2004

*  Recent Topics

*  Fog Creek Home