Hi Steve,

To go along with what David said, I think typed datasets can make coding easier. Instead of accessing the data like a collection, you can use syntax which is more like VFP. There is a section in the VS.NET help file called Typed versus Untyped Datasets that has this example and more info:

Accessing data with Typed Dataset:
string s = dsCustomersOrders1.Customers[0].CustomerID;

Same with Untyped Dataset:
string s = (string) dsCustomersOrders1.Tables["Customers"].Rows[0]["CustomerID"];

Obviously the typed dataset is easier to code and read, and is supported by IntelliSense. In addition, the last time I checked, Crystal Reports would not accept an untyped dataset. Still, I know what you mean about the maintenance headache. A couple of limitations I found are 1) changes to the SQL statement would require the XSD to be regenerated. This means that a SELECT * query would require the XSD to be updated anytime the underlying structure changes. 2) It may not be possible to create SQL statements dynamically, specifying fields, etc. at runtime.

Do these limitations sound familiar? Like a VFP remote view maybe? Once I realized that I was already dealing with these types of issues in VFP, it made it easier to accept the limitations. I *think* you may even be able to put multiple queries in a single XSD file, which would be more DBC-like. Now, all we need is an XSD Editor product to make maintenance easier ;o).

>Can anyone point me to a good reference to help me understand typed datasets?
>
>My understanding to this point is that a typed dataset simply has an XML Schema associated with it. I'm doing this at runtime by using the ReadXmlSchema() method of the dataset.
>
>I'm a little vague as to the utility and advantages of using typed datasets, and it would seem that maintenance of the XML Schemas for each dataset used in a complex application could become a bit of a headache. I want to learn more.
>
>Thanks.