>>>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.

Yeah, but there may be more than one table in the biz object. My bus objects are hierarchical. So I have Invoice and I have lineitems both of which have separate datasets. But Invoice runs tons of 'private' queries etc and those go into its own dataset for example.

It works real well actually and the overhead of a pure Dataset is minimal. Now a typed dataset on the other hand probably wouldn't be.

>
>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.

No way. Not in a Web app... In a Web app you usually do small things at a time. If I want to look at an item I don't want or need to have anything happen with my customer table. Again I suspect the overhead isn't gigantic, but its there. Maybe I'm overreacting on this.

In playing around with this I found lots of quirks in the way the DataSets work when they are 'generically' referenced. Lots of problems coercing the DataSet into the bus framework. I got it all working, but it's not clean in a generic environment.

If I think of the scenario I would have to use it would be create a typed DataSet from the entire database, then force that typed dataset into the busobjects so that the generic code can act on the typed dataset. So all objects would have this dataset instantiated with all the associated overhead...

I went ahead and created a small build to build a DataRow wrapper that is fairly lean and provides an as needed wrapper. So I can use my bus objects like usual and when I need typed access I can just store the row and it's available that way. This way read operations that load up data into lists etc don't take the hit...

Anyway, it looks like it works ofr you. I hate reinventing the wheel too, but sometimes it pays off giving something a little more flexibility without so much of a hit <g>... and the builder makes it easy to pick what I want.
OTOH it was pretty trivial to build this code gen <g>...

+++ Rick ---