Steve,

I would've jumped into the fray a little earlier, but I've been on vacation (well, a long weekend anyway <s>).

I'd like to expand on Morgan's comment a little. One of the reasons that we further sub-class the Typed DataSet is because when you generate the XSD from the Stored Proc (as Morgan explained), the table names are assigned by .NET to be table, Table1, Table2, etc... We sub-class the auto-generated Typed DataSet and add properties so that we can reference the table names by more intuitive names. (We also add more methods to our DataSet subclasses ... as Morgan said, it adds further flexibility.)

Here's an example of the tablename properties:

[System.ComponentModel.Browsable(false)]
[System.ComponentModel.DesignerSerializationVisibilityAttribute(System.ComponentModel.DesignerSerializationVisiblity.Content)]
public tableDataTable Customer
{
    get {return this.table;}
}

[System.ComponentModel.Browsable(false)]
[System.ComponentModel.DesignerSerializationVisibilityAttribute(System.ComponentModel.DesignerSerializationVisiblity.Content)]
public Table1DataTable Orders
{
    get {return this.Table1;}
}

[System.ComponentModel.Browsable(false)]
[System.ComponentModel.DesignerSerializationVisibilityAttribute(System.ComponentModel.DesignerSerializationVisiblity.Content)]
public Table2DataTable Details
{
    get {return this.Table2;}
}

We use a VFP utility that we wrote to auto-generate the above code (using _Cliptext and just copying the .NET autogenerated Typed DataSet, then creating your sub-class and pasting the results from the VFP utility into the new class.)

~~Bonnie



>>It is pretty simple to write a small application that can generate the XSD for you from the table structure or from the results of a stored procedure.
>
>How would you do that from a stored proc?
>
>> Add the XSD to your project and your good to go.
>
>Don't we need more than just the XSD? If I correctly understand what David and Joel have explained, the whole point is the DataSet-derived subclass that's based on the schema.