ADO.NET 2.0 Comings and goings

I thought I would share with you some of the significant changes that I have encountered in the course of some work that I am currently doing with ADO.NET 2.0.

Goings (as in going, going, gone !)
Already in Beta 1, the following features have been dropped:

(1) Server-side cursors & Paging
I for one, am disappointed  to see Server-side cursors (i.e. SQLResultSet) & Paging being dropped.  These were both features that were highlighted in the early presentations on ADO.NET (eg at PDC). 

Server-side cursors is a feature that developers moving to .NET immediately notice is missing.  Part of the problem, and one of the main reasons it has been dropped, is that the current model is far too easy to be misused.  The other main reason is that it is hard to scale. 

Paging (i.e. Command.ExecutePageReader) was built on top of the server-side cursor technology, so it too is gone.  This is a feature that developers (especially web developers) are always asking for. I really thought that this time MS had a very good implementation.  It wasn't perfect, but definitely very reasonable and usable.

Hopefully we'll see their return in Orcas (Longhorn version of Visual Studio).

(2) Data Components in the Toolbox
If you are used to building your data access code by starting with the Data Components on the Data Tab of the Toolbox, you may be a little distressed and concerned when you open VS Beta 1 and can't find them there.  This of course, is "By Design" J   Microsoft clearly wants to nudge us into taking advantage of the new typed DataTables and TableAdapters.  If you really, really want to insist on using the old untyped controls and components, you can manually add them back to the toolbox.  I strongly suggest that you don't…By leveraging the new partial class technology, the new typed DataSets, DataTables, and TableAdapters are much easier to use and to extend.

You can get more details from Steve Lasker's excellent post.

In the next Community Technology Preview  / Beta 2, the following features will be dropped:

(3) Transaction property of TableAdapter.  For details see Steve's other post.

(4) IXXXTableAdapter
If you create a DataTable named XXX and thenlook at the code that is generated for this class, you'll notice an odd (at least to me) implementation fact.  Rather than having the XXXTableAdapter class simply implement the defined methods (various Get, Fill, etc.) , an interface named IXXXTableAdapter is defined and then implemented by the XXXTableAdapter class.  This interface is not used anywhere else and I really couldn't see any added-value to this extra step.  Apparently Microsoft agrees and this approach and interface will be dropped.

Of course, not only are features going away, but lots of features and enhancements are coming along and being added.  Many of them are still under wraps, but let's talk about this one.

(5) Name changes for the DataConnector and the DataNavigator
Coming in the post-Beta1 builds you will see the names of the DataConnector and the DataNavigator classes changed to BindingSource and BindingNavigator respectively.  This won't be adding any functionality per se, but it will make it much clearer and easier to understand the role of these classes.  

When I first started exploring the DataConnector, it was not totally obvious what its purpose was.  I was able to pretty much figure it out, but I still thought that maybe I was missing something.  I also felt that it would be a bit difficult to explain to others what exactly it was/did.  With the upcoming name change it becomes pretty obvious what the DataConnector/BindingSource role is – to be the "binding manger" for a data source. It will also be far easier to use than the 1.1 binding context. 



  • As for point no 1: this is goodness IMO. If anyone really wants to use server side cursors, they can still use the underlying resource manager's cursor implementation.

  • Re server side cursors and scaling. There are many times when I have an application that I know does NOT need to scale to have 000's of users. Sometimes an application might just have a few users and will stay that way.

  • Tom,

    You're obviously 100% correct on the current ASP.NET implementation of paging. I didn't think mention, because to me it was "obvious" that this was the way it worked, since I've known this for a long time. But, yeah, when I first realized it I was surprised and disappointed. The same goes for my students and clients - although they tend more to be disappointed and angry.

  • Alex,

    I would tend to agree with you. I would prefer to have the choice (and responsibility) of choosing the right technology for teh task at end, rather than having it eliminated because it could easily be misused by others.

    On the other hand, :-), as Niels points out, the feature is not totally eliminated - you just need to work a little harder to get to it and use it.

  • Hi Jackie,

    Long time, no see. I hope you are doing great!

    I expected to see a mention about ObjectSpaces in this post when I read the header. What's your take on that?

    Best Regards,



  • Jimmy,

    Thanks for stopping by...

    Of course, you are right about ObjectSpaces also being droppped - I guess I forgot to include them since I considered that "old" news that had already received alot of attention.

  • Hi Jackie,

    Ah, OK! Talk to you later!

    Best Regards,



Comments have been disabled for this content.