Freigeben über

Whidbey ADO.NET beta 1 has shipped. Favorite features

  • Artikel

Well, we have shipped whidbey beta 1. This is a great release for the ado.net team, we have managed to not break away from an existing data model while adding great new features. Everything you have will continue working as is, we have fixed old problems and added features to address the biggest shortcoming of previous releases, there are a few features that I am really excited about. I would like to take the time to blog on individual features, one per week for the next few weeks, drop me some feedback on the order that you would like to see these or with suggestions for ado.net features that I might have missed.

  • Distributed Transactions with System.Transactions. Finally managed distributed transactions are easy to use, leaner meaner faster and as robust as always, this is a really good feature.
  • SqlBulkUpdate. Bulk update is nothing new, but now you can do it from managed code and it is faaast. Not able to insert 100.000rows of data into sql server with ado.net 1.1? Take one of these SqlBulkUpdates and call me in the hmm.. never mind you are probably done by now <g>
  • Adapter batch update. Nothing like a good batch to wake you up in the morning, hey seriously this is not rocket science but it is about time that adapter update worked
  • Provider SDK. So you want to be a ..managed provider writer? Do you hate to write a lot of code? Do you want pooling and performance counters to just work? boy do I have a deal for you! How much would you pay for this once in a lifetime opportunity? Well I think you know where I am going with this, we have made common classes for all of our providers and abstracted pooling and perf counters, this is not a vanilla sdk, all of our providers derive from this common model and so can you.
  • Provider factory. This is not really one of my favorite features, but writing about it allows me to bash on UDA(which is imo a bad thing). One of the biggest requests when ado.net shipped was UDA, universal data access. I did not like it then and imo I don't like it now ( I have to put in the “imo” any time I say something like that, but trust me, UDA is Eviel “imo“). This feature looks like UDA, smells like UDA but it is (thankfully) not UDA. Thanks to the common classes you can now use a provider factory to write provider independent code, at runtime you can connect to Sql or to Oracle with the same provider independent code. Performance? the exact same performance that you would get by connecting with OracleClient or SqlClient. Why is this not UDA? well this factory model breaks down any time you do _anything_ (I forgot to mention in the post below that I love _underscoring_ too) that is backend dependent. Not UDA, but an interesting feature.
  • SqlNotfications. I am bluffing I don't know anything about these. I am putting this in here hoping nobody will notice.
  • Pooling improvements. I am not kidding about this one, I know about pooling. If anybody votes for this one they are going to get hit with more information than they can shake a stick at.

Hey its friday, calling it a day.

Rambling out.

Standard disclaimer, this post (and everything in this blog) is just my opinion, information here is provided “as is” and confers no rights.

Comments

  • Anonymous
    July 03, 2004
    Thanks for the provider factory feature. You call it an 'interesting feature', but I think its a very important one. Ive missed something like that in the framework since the 1.0 release, and promptly built my own version. I guess I will now have to retire that code once 2.0 comes out (which goes for a lot of code Ive written actually...)
  • Anonymous
    July 03, 2004
    Well, I’m especially keen about learning the innerworking of the distributed transactions capabilities with System.Transactions and the changes of this API / model compared to the one we have with the enterprise services / DCOM.

    Another topic, which also has my interest, is the SQL notification, so I’m calling your bluff :) But he… if you rather want to write about those other dull topics… be my guest.

    Just kidding, anyways looking forward to read your blog, cheers.
  • Anonymous
    July 04, 2004
    OK, I'm game, why is UDA evil?
  • Anonymous
    July 04, 2004
    The comment has been removed
  • Anonymous
    July 13, 2004
    Angel,

    Re: Adapter batch update. Nothing like a good batch to wake you up in the morning, hey seriously this is not rocket science but it is about time that adapter update worked

    I've been testing batch updates and have found that batching in Beta 1 (with any batch size greater than 1) causes a performance hit, not an improvement, using networked and local SQL 2000 Server instances.

    There's a thread about this on the microsoft.private.whidbey.windowsforms.databinding newsgroup ("Performance Issues with Batched Updates").

    --rj
  • Anonymous
    July 13, 2004
    The comment has been removed
  • Anonymous
    July 14, 2004
    Hi, Angel,

    Thanks for the response.

    If you use value-based optimistic concurrency and the table have several columns, it doesn't take a lot of updates to reach 2000 parameters. In Beta 1, timestamps with SQL statements are far more efficient because they send only the updated value(s) and the timestamp value(s). (Unfortunately, I can't get stored procedures with timestamps to work, per that thread.) Is there a plan to do the same for value-based updates?

    My value-based tests with the Northwind Orders table shows 40 params per update. Failure on 52 (not 51) updates/batch indicates that the max looks like it's 2048 params. Seems to be easy to limit the batch size based on (2047 / DataAdapter.Parameters.Count).

    The number of parms for timestamp-based concurrency management varies with the number of columns updated. Is there a fool-proof method of determining the maximum batch size in this case?

    Thanks in advance,

    --rj
  • Anonymous
    July 14, 2004
    The comment has been removed