I was having a chat with David Sceppa about TableAdapters recently when he mentioned that in the final VS 2005 bits, the TableAdapters will use timestamp fields for concurrency. I told him flatly I didn't think it worked, but I was wrong. If you create a Table in a Typed DataSet in VS 2005 and include the timestamp field in the select statement, it will use the timestamp field for concurrency. Awesome!
(Note: ASP.NET 2.0 DataSources use their own source code for concurrency so that doesn't work at all in DataSources AFAIK.)
I have been a fan of Typed DataSets since the PDC Beta of .NET. I’ve been asked to detail my recent criticism of Table Adapters in the .NET 2.0 Typed DataSets. Here are the points that I am most concerned with:
Anything I missed?
For those who do not know yet, the XML integration with the DataSet is very powerful. Most of the integration is about filling and getting XML from your DataSet. But the XmlDataDocument is really cool. Simply by assigning the DataSet to the XmlDataDocument, you can work with the DataSet data either relationally (through the DataSet) or hierarchically (through the XmlDocument). So, next time you need to transform the DataSet data or just run an XPath query, assign your DataSet to an XmlDataDocument and watch the magic begin...
Why is everyone so down on using DataSets in .NET Web Services? Sure, I’ll admit that using DataSets directly as Web Service parameters are indeed a problem. But why throw the baby out with the bath water?
For the uninitiated, DataSets are a problem as Web Service parameters because XML that is automatically generated as the parameter is a DiffGram of the DataSet. Unfortunately DiffGrams are simply not interop-friendly. At the end of the day the obvious use of DataSets in .NET Web Services are simply a bad idea.
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||188.8.131.52||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.24628.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|