Sharing the goodness…
Beth Massi is a Senior Program Manager on the Visual Studio team at Microsoft and a community champion for .NET developers. Learn more about Beth.
More videos »
Last night I spoke at East Bay.NET UG on some of the new features in Visual Studio Service Pack 1 focusing on client and data. I did a whirlwind tour of new SQL 2008 data types and Sync Services enhancements, ADO.NET Entity Framework, ADO.NET Data Services, WPF performance and data enhancements, Client Profile Deployment, VSTO Add-In Host Controls and Smart Tags, and VSTO deployment and end-user install troubleshooting improvements. There is just so much packed into SP1 that next month we'll be doing a talk on all things web including ASP.NET Dynamic Data and MVC.
The talk went really well and it was a lot of fun. I've uploaded the presentation and demos onto Code Gallery here: http://code.msdn.microsoft.com/whatsnewvs2008sp1
PingBack from http://www.easycoded.com/whats-new-in-visual-studio-2008-sp1-client-and-data-features/
Awesome sense of Community...You Rock!
My only problem with all this new stuff and new features thats coming out is that I have to learn it all... and I'm so behind the times as it already, I'll be 30 before I get up to date...
I have some questions about dataset in VB 2008.
I have a dataset which encompasses four related tables. I execute some queries (join) on this dataset. Is it better use single dataset or multiple datasets? In other words, when my query don't involves the entire join-path but only one or two tables, is it better create a new dataset which contains only the two related tables?
Another question: what's the life-time of the dataset? Is it the same life-time of the form? I have to explicitly destroy the dataset?
The last question...
When I want some information about a table (es.: only CustomerID and Name) what's the correct way to obtain informations (scalar query, fill method, linq, ecc.)?
Thanks in advance
It totally depends on how you want to break up your datasets because they can be used across your application by many forms. Keep the tables together if the entity is often updated together. If you split the tables up into separate datasets you will lose all the benefits of relations which are necessary for master-detail scenarios. I would create stored procedures for update/insert/delete and even select because that will allow you to keep the data-related code in the database and reuse them across TableAdapters which makes the maintenance of them a bit easier.
You can even create the datasets with views of data that don't map exactly back to the database tables but instead are a view of multiple tables. In this case you would need to specify custom stored procs to update/insert/delete anyways, so maintenance is the same for those. (here's a discussion on this: http://blogs.msdn.com/bethmassi/archive/2008/10/15/editing-data-from-two-tables-in-a-single-datagridview.aspx)
For lookup tables (or other read-only data), you can separate them into separate datasets because they do not need to be related except by data-binding most likely.
The lifetime of the dataset is the same as any other object scope. If you create the DataSet object on the form then it will be destroyed when the form is destroyed.
You can use LINQ to Datasets to extract just particular columns from a dataset, see this video here: http://msdn.microsoft.com/en-us/vbasic/bb737877.aspx
If the data is in the database then you can create a new method on your TableAdapter and specify a parameterized query. Whether it's scalar or a result set depends on how you wan tto use it in your application.
Thanks....it's very clear. I'll try LINQ too.