>>Perhaps we're looking a little too granular - <

Yes, sounds like it ...

In case you might need some ideas:

We have DataSets that contain many tables (a parent and many children).

We have a separate DataAccess layer that handles *all* the reading and writing of data. No other layer may talk directly to the database ... *all* access goes thru the DataAccess Layer.

Then, we have a Business layer. This handles things like rules before passing the DataSet on to the DataAccess layer to process.

~~Bonnie


>Perhaps we're looking a little too granular - we have business objects and business object 'collections' - I guess we need to put the conenction on the collection object ...
>
>Thanks
>
>
>>Ken,
>>
>>Don't use multiple connection objects. Seems to me that if you have a business reason for grouping various items together in one transaction, then there should be a business object that does this. You could have the data in multiple DataSets if need be, but you'd have one connection object and one transaction wrapped around multiple SqlCommand.ExecuteNonQuery() method calls.
>>
>>DataSets are not business objects ... they are simply data.
>>
>>~~Bonnie
>>
>>
>>>How do you manage transactions across multiple datasets (business objects) when each business object is using its own connection object? The ADO.Net model seems to be “connect, get/write data, disconnect” – but how do we get that to play with the idea of a multi-bus-object transaction?
>>>
>>>Thanks,