George, Before the "Data Access App Blocks"(DAAB) came out I wrote a similar class to shield the System.Data specifics. To my mind it didn't make sense to return an DataTable nor DataSet (like DAAB seems to) as the return value from a procedure due the problem you are are experiencing. It made more sense to do it like the DataAdapter does and have a method like: public int FillDataTable(DataTable table, IDbCommand command) to which you pass a reference to your table to be filled. Therefore, you'd end up with client code like so: FillDataTable(pubsData.Publishers, selectPublishersCmd); FillDataTable(pubsData.Titles, selectTitlesCmd);
I think of the DataSet and DataTable /more/ (although not exclusively) as a repository owned by the client which is to be filled, as opposed to some entity necessarily being created and passed back by the server. Hopefully that makes sense to you too! Cheers, Duncan Smart [EMAIL PROTECTED] On Sun, 21 Apr 2002 22:56:38 -0700, george antony <[EMAIL PROTECTED]> wrote: >The Data Access Application blocks gives a set of >methods which can be used to return a >dataset,datareader etc . This dataset has to be copied >into a specific datatable which we have built in a >custom class which in turn derives from a dataset >class. >From our research we have found that this is not >possible. DataTables in a dataset are readonly and >can't be assigned to. We can add rows to a datatable >but we can't assign a datatable from one dataset to a >datatable in another dataset directly. > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
