I got a strongly typed DataSet and I'm trying to override its DataAdapter Update method.
The reason for that is that I want to collect some information about the DataSet before saving changes back to the database and do something with it after changes are saved.

I know I can register for the RowUpdating and RowUpdated events but they are instance specific.
I would like to build something more generic without changing the name of Update method.
From what I know you cannot override virtual method on a partial class.

Please advice.

Hi Lior,

RE: "From what I know you cannot override virtual method on a partial class" --- Correct, the patial class is the same class with the generated TableAdapter class so, you cannot override it.

You can only use override only in a derivedclass -- so one suggestion may be to use the derived class.

On the otherhand, you should review your scenario and see other approaches like can you trigger an event before call the DataAdapter update.

HTH,
John

You could avoid using TableAdapters altogetherand write your own classes for handling DataAccess. IMHO, TableAdapters cause more problems than they're worth.

---

~~Bonnie Berent [C# MVP]

This is exactly what I decided to do. In fact, I'm extending the Data-Adapter created by the wizard.
This way I can still reuse all the Fill methods and changing only the Update method.
Thanks.

BonnieB,

I would love to hear what is in your mind about the pros and cons of TableAdapter. :)
Thanks!

John

Lior83,

"In fact, I'm extending the Data-Adapter created by the wizard.
This way I can still reuse all the Fill methods and changing only the Update method."

Why not, you should be free to add new methods or method overload in the partial class.

John

John,

The problems that I see with the TableAdapter is the inflexibility. The generated class tightly-couples the DataSet to the database, and I don't believe that DataSets should be used that way.Iuse DataSets simply as a data transport mechanism. My DataSets know nothing about where their data comes from, nor should they.

OK, technically speaking, the DataSet classdoesn't know about where its data comes from, just because I'm using a TableAdapter. But the fact the TableAdapter gets generated inside the DataSet.designer.csmeans that the DataSet DLL is no longer database agnostic, and that's a verybad thing for correct client-server/SOA architecture. There is no more separation of layers when done this way. The DataAccess classes should be a totally separate layer with their own DLLs, just as the DataSet should live in their own DLLs.

There are other things ... I wrote something up once about what I didn't like about TableAdapter and I can dig it up and post if here if you'd like me to diss them even more. ;0)

---

~~Bonnie Berent [C# MVP]

Bonnie,

I agree with every word of yours. I spend quitesome time thinking about it and I came to the same conclusions.
MySELECT statement for thedatasetbrings columns fromdifferent tables (using JOIN) and the adapter generated by the wizard don't know how to handle it.
This is why I got my own DataAdapter. I can resolve changes, pass database connection in an easier way, hook to the adapter update events and so much more...
I would love to read what you wrote about TableAdapters.

Thanks for the reply.

There is a little bit history of the TableAdapter. In V1, VS2002, we do not have TableAdpter, pure typed dataset.The experience for data accessing is not so great as we don't have a strongly typed DataAdapter, this is especially hard for for beginners. So the TableAdapter was introduced in VS2005. As you said, the DataSet is still a DataSet and you are free to use your own version of adapter. I agree withyou that TableAdapter should be in anotherfile if you want to build true N-Tier application. So there is the DataSet and TableAdapter seperation in VS2008. See some sample articles bellow:
http://blogs.microsoft.co.il/blogs/bursteg/archive/2008/02/10/how-to-build-an-n-tier-application-with-wcf-and-datasets-in-visual-studio-2008.aspx
http://blogs.msdn.com/smartclientdata/archive/2006/02/21/SeperatingTypedDataSetsFromTableAdapters.aspx#comments

Hope this help.
Thanks!

John

OK, I didn't know that, so I looked into it a little bit further. I'm sorry, I still don't like the way it's implemented, I think it'sonly slightlybetter. At least the TableAdapter can be split out from the DataSet.

(BTW, for those who didn't read the above links, what you do after you've generated your TableAdapter in your DataAccess project, while in the DataSet designer, go to Properties, and then specify where your DataSet project is ... the Designer.cs file then gets copied to that project. The TableAdapter stuff gets removed from that copy, and the DataSet stuff gets removed from the original).

But, the .xsd still remains with the DataAccess and what gets put into your DataSet class no longer has an .xsd. I think that's backwards. The .xsd contains the schema for the DataSet ... why would it remain with the DataAccess class? It really should have been moved into the DataSet project, along with the generated Designer.cs file. I think the problem was that so much of the connection info and such for the TableAdapter got put into the .xsd to begin with, which in my opinion never should have been done in the first place. The .xsd should *only* contain the schema of the DataSet.

Sorry, I still can't recommend the use of TableAdapters. =0(

---

~~Bonnie Berent [C# MVP]