>A trick we used early on to generate .xsd's for us was to use the DataSet.WriteXmlSchema("MyFileDataSet.xsd"). We wrote a little utility program that, after you told it what Stored Proc you wanted to use and what you wanted to name your DataSet, it would call the Stored Proc, Fill the DataSet, then write out the Schema to an .xsd file. You can then add that .xsd to your project (we typically have separate DataSet projects) and generate a Typed DataSet. You can then drop those on your Form (when you drag a DataSet from the ToolBox to your design surface, you'll get a wizard that will help you choose the Typed DataSet to add to the Form).
>
>~~Bonnie

When I first read this I did not truly appreciate the technique.

Having gotten into this a ways I am now convinced that I need to write code to help generate and maintain my datasets for me.

I already have a data access layer written that is designed to be provider independent, and is a fully separate layer from my datasets. (I modeled it after the code you gave me. Which was great BTW!)

The code I am writing now will contain the table definitions, stored procedures etc. and be able to generate the requred database on the provider and generate the typed dataset code for the project.

I am wondering if I even need to use the XSDs or... since my code will basically replace the built in designer, if I should just go straight to generating datasets in code. Any advantage in creating the XSDs?

Also I am considering putting my business logic into my datasets, do you see any inherent problems with that? (Basically making the Business Object a subclassed dataset.)