>>Generating the xsd wouldn't be a problem if all I had was a single dataset but as I mentioned every business object uses its own.<

So you only have one DataSet per BizObject? We haven't done it quite that way. Basically, everything centers around functionality. So, for example, the Personnel BizObject will contain everything needed to get any kind of Personnel info, including things like Lists of Personnel, and update any changes made to the Personnel DataSet. It handles the Biz stuff and then calls the appropriate Personnel DataAccess methods to talk to the back-end datastore. All these classes and methods passes around various types of Personnel DataSets.

The DataSets themselves are all in their own class (their own project/.DLL) ... and that is also by functionality. So, we'll have a project for Personnel Data and it will contain all the various DataSets needed by the Personnel "module". Same for any other "entity" or "functionality" in the system.

Anyway, I guess what I'm getting at is that for the way we've designed our system, the Typed DataSets work really well. And, as Morgan pointed out in another post, they're extremely flexible because we can (and do) add additional functionality right into the DataSet.

>Even with the single table I have a problem with the fact that the typed DataSet when it pulls the first data generates all the tables.<

I don't see why this is a problem.Typically, wouldn't you anticipate using most of the tables in a DataSet anyway (at least most of the time)? If not, perhaps you need to define additional DataSets for different jobs.

~~Bonnie