DataSet feature requests

We have begun the initial planning for the next version of the DataSet (post VS 2005).  If you have a feature you would like to see, let me know.

I can also pass on feature requests for other components in System.Xml and to the proper folks.

Comments (21)
  1. Don says:

    A pattern or feature that supports multilevel Undo.

    (1) I want to use a (possibly disconnected) DataSet to hold the state of my application.

    (2)Any modern app must have multi-level undo.

    It would be a HUGE help if there were some kind of journalling/checkpoint/transactional function in the DataSet that could be used to implement multilevel undo.

    (If there’s already a good way to do it, then PLEASE while you’re in a planning cycle try to plan some time for someone to write about how to do this because patterns for implementing multilevel undo apps in the .NET framework have not been effectively communicated and evangelised into the community)


  2. I’ve only used beta 1 of C# Express, so forgive me if this feature is already there:

    I’d like to be able to specify a sort criterion in the GetChildRows method.

    Currently you can specify an order in the Select method, so that the array of DataRow objects returned is sorted. I’d like to see an optional second parameter to GetChildRows that works the same way.


  3. Gia says:

    produce xsd schema that validates the xml instance

  4. Bring back paging support that was removed from Whidbey! This was a huge mistake to remove in my humble opinion

  5. Jeff Davis says:

    I’d like to see automatic saving of master-detail dataset relationships inside a transaction.

  6. Bill Vaughn says:

    It’s late here and my mind is not clear so pardon the ramblings.

    I think (as much as anything) we need to add more education to the data structures so the expectations and best practices are obvious. Should Microsoft create another offline data store or make SQL Express lighter and smaller? If one can wedge SQL Server into a phone, I expect you can get it small enough to handle a small offline data store without reinventing the wheel.

    Making the dataset (or whatever you call it next time) suitable for everyone makes it suitable for no one. I think there are specific requirements for ASP that don’t work well for client/server or web services—each architecture has its own needs that make the object harder to use in the others. Microsoft has over-emphasized ASP and Web services despite the fact that the vast majority of their customers were designing and deploying client/server Windows forms applications.

    • For the lower-skilled developers who want to be able to build updatable data structures, I think Microsoft and Visual Studio needs to do more with code generation that’s cognizant of serious concurrency models—including TimeStamp, changed columns, PK only, and (as it is now) all columns. This technology needs to be incorporated in the (now busted) CommandBuilder. But more serious developers would like the better productivity of best-practice action command code builders.

    • I would like to see a new way to let the action queries interface back to ADO to report how the action command went. That is, did the update/insert/delete succeed or fail? Did it succeed, but is there a warning message (too few socks remain in inventory). Did it fail for concurrency reasons or for some other reason (far more likely). I suggested in my blog this week a way to give developers a choice to pass back a “smart” Return value or OUTPUT parameter. Consider that many applications use complex stored procedures to perform action operations. They update one, two or a dozen tables in a single operation. Signaling success with rows affected = 1 is a simplistic (and hard to use) interface.

    • I would like to see properties on columns so we could mark specific columns as RO. This way we could give Visual Studio a chance to build more intelligent action code. We don’t need Visual Studio building action commands on columns that can’t be updated. Sure, some expressions are obvious, but what about columns that the user does not have permission to change?

    • I would like to see better integration of user-defined properties. We need to be able to define (through some mechanism) additional properties on columns, tables and other objects—more than just Value. For example, description, currency, language, min, max, mask, default all come to mind as useful column properties. I wrote a paper years ago about how to use Extended Properties in SQL Server to implement these properties. They need to be on all objects—not just the columns.

    • Lots of stored procedures are designed around default values. That is, you can execute the stored procedure with very few parameters—or none at all. This is not easy to do in ADO.NET. The code generators build all of the parameters. If we had an option of marking a parameter as “don’t submit”, the last-second interface could skip those so marked.

    • Client/server applications should get back the ability to create and manage server-side cursors. No, these need to be Keyset – not dynamic. Developers need control over the cache size and the features we had long ago in ADO classic 1.0. These cursors should permit creation of pessimistic locks.

    • Visual Studio and ADO need tighter integration with the user/login/schema/rights management paradigm. In Whidbey there are no tools to handle this. Yukon has the tools but they are far too complex for the ordinary user. I envision wizards to walk users through the process of setting up users/groups/roles/schemas and assigning appropriate rights to these.

    • I would hate to see creation of another SHAPE syntax overhead black box that handles client/side SELECTs.

    • When the new paradigm is created, consider that Microsoft has changed the programming practices, techniques and the way that Whidbey generates and manages this code every two or three years for as long as I can remember. This constant stir makes IT managers crazy. While it keeps authors like me busy rewriting books, it cost the entire industry a great deal to retrain their development teams over and over again. I expect that some of the resistance you’re seeing in adoption of .NET is the weariness of the development community—beyond those enamored with new technology. In the background is the specter of Visual Basic 6.0 and how Microsoft has stopped supporting this very popular language long before the development community has moved on to the new technology.

  7. Giuseppe says:

    Allow to set the RowState of a Row Manually. Thnx 🙂

  8. Lu Feng says:

    Please provide a sort method that can help us sort the original data in a dataTable. I don’t like use the sort method in DataView:)

  9. lynn eriksen says:

    Yes. Multi-level undo would be cool.

    If the COmega data/sql ideas land in the platform, it would be great if we could use the dataset with this.

  10. Sahil Malik says:


    I have quite a few good participating comments on my blog entry with a few good suggestions there too.

    – SM

  11. We’re working hard with DataSets for the last 3 years and we missed some features:

    – Don’t mark ColumnName as internal. We have all of them in a shared Assembly, because we use the typed DataSets on Client and Server.

    – Default value and maxlen and foreign key constraints should be read from the database.

    – We miss a general update mechanism of typed DataSets when the database has changed .

    – In case of a constraint error, it would be nice to add the column and the type of error in the exception message.

    – We trapped a lot of times in the deleted Row pitfall, while accessing the row.

    – We wrote some utility methods to :

    – fill default values into a new row

    – copy a row into another dataset

    – copy the whole dataset into another one

    – initialize the dataset’s increment and seed to negativ for newly added rows

    – create a table copy of a view

    – add or remove additional filters to a view

    – get the names of columns with changed values

    – ask whether a column has changed values

    contact me through

  12. How about the ability to have one datatable definition, but have it included in many datasets? For example I have a Notes table that is referenced in many other tables – I should be able to create one Note DataTable Type and have it contained in multiple DataSets.

    • Have an option to deleted rows as normal rows. I want to iterate over all the rows and ask for the rowstate, and access the values as if they were normal rows. Accessing deleted rows today is a pain

      – I want to do a .Find() by any unique key.

      – When I have master/detail tables I want to set as ‘Modified’ the parent when I modify the childs. This is because I need to validate the whole entity when something changed in it, and to know if something changed I need to traverse all the child rows to ask that.

  13. Please nix the DataSet from the framework entirely and re-focus on the domain-oriented data access work you were doing prior to Tech-Ed 04. If that’s not possible, please have the Visual Studio team desist from distracting .NET culture from Domain-Driven Design with that nasty, nasty typed DataSet RADule 🙂

    I hope this helps,


  14. marco says:

    Surely n.1: allowing (filtered) joins. If you have two datatables and a relation, you should have a way to do joins (other than the simplistic getchildrecords).

    example: I have a CookieType and a Cookie table.

    If I want all the cookies that are of a given type, it’s easy, but let’s say I want to know all the types of cookies for the coookies where cookie.price==5.

    That would be nice!

    n.2: Faster and smarter merge.

    hope it helps.


  15. yuri says:

    XSLT processor which optimizes applying templates when multiple templates have similiar match with the same priority, for instance differfence in value of an attribute

  16. Sahil Malik says:

    Please nix the DataSet from the framework entirely

    <– I don’t advocate that for multiple reasons.

    • Make DataTables as standalone as DataSets to allow for their use as Objects ("on steroids") and let these be referenceable in DataSets. (ie. Allow combining of standalone DataTables to DataSets)

      – Provide DataSet Level Persistence (ie. Save all data that is changed in a given dataset by walking the relationships and doing all the appropriate saving automatically). I do have code for this already which I would be more than willing to provide (except that I would rather be able to do this out-of-the-box)

      For more details or any comments please feel free to email me at

  17. Tim Odell says:

    I would like a method that creates a DataView and a new DataTable based on two or more related datatables. I would like it to behave exactly like a SQL Join Statement.

Comments are closed.

Skip to main content