Working with data

	.NET - Data Binding With Visual Studio 2005 and Data Sources Window, integrating data into smart device applications is easier than ever before. The Data Sources window displays typed DataSets, Web service data, or custom data implemented in business objects in an easy-to-use TreeView menu. You no longer need to write complex data binding logic for your .NET Compact Framework applications. Instead, you can simply drag items from the Data Sources window directly onto a form and Visual Studio 2005 will automatically create a data-bound control based on the properties of the bound data source. The IDE auto-generates all the code necessary for binding the data to the controls on the form, offering a faster and more reliable development experience.
	New DataSet Features in Visual Studio 2005 Learn about the new features in the typed DataSet class and the new TableAdapter class that are generated by Visual Studio 2005, as well as the tools for designing these classes. Also learn about the new BindingSource and BindingNavigator components, and see how to use them to rapidly build flexible, data-bound WinForms applications.
	Building a DAL using Strongly Typed TableAdapters and DataTables in VS 2005 and ASP.NET 2.0 One of my goals over the next few weeks is to publish a number of quick tutorial postings that walkthrough implementing common data binding design patterns using ASP.NET 2.0 (master details, filtering, sorting, paging, 2-way data-binding, editing, insertion, deletion, hierarchical data browsing, hierarchical drill-down, optimistic concurrency, etc, etc). To help keep these samples shorter, and to help link them together, I’m going to use a common DAL (data access layer) implementation across the samples that is based on SQL Server’s Northwind sample database.
	Hierarchical TableAdapters 301 One of my Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition) readers commented that he was still having problems setting up a TableAdapter that was fed from stored procedures instead of base tables. With help from Steve Lasker and Beth Massi at Microsoft, I was able to get a fairly comprehensive application together that demonstrates most of the issues one encounters when attempting to build a forms-over-data application that uses stored procedures instead of tables as the rowset source. Although I don't have enough space here to walk through this process step-by-step, I'll give you a roadmap that should help you avoid the pitfalls.
	Using the Visual Studio 2005 DataSet Designer to build a data access layer In this article Brian Noyes shows how to use the new features in the Visual Studio 2005 DataSet Designer to create Typed DataSets and Adapters to provide a data access layer for your applications. He then demonstrates how to extend the generated classes using with help from partial classes features.
	Customizing the connection string for TableAdapters Visual Studio 2005 now leverages the strongly typed settings file which wraps app.config. With connection strings stored in app.config/Settings, developers can centralize their connection strings across their application.
	Colby Africa: Microsoft .Net 2.0 - Strongly Typed Datasets, App.Config, and Overriding Connection St We use strongly typed datasets in our data access layer (DAL) with various levels of satisfaction. The DAL is implemented in a class library. Connection strings for the data sets are configurable at design time through the dataset designer and are stored in an app.config file. Class libraries are packaged as DLL's and therefore don't have a config file (.Net doesn't support myFile.dll.config). The reason for this is pretty simple: one config file per app domain. When the class library is complied into a DLL, the app.config file gets munched and converted into a resource.
	Changing the connectionstring of a wizard generated TableAdapter at runtime from an ObjectDataSource The Visual Studio 2005 Dataset designer allows you to create a DAL using a typed dataset and easily bind this to a GridView with the help of an ObjectDataSource. By default, in the TableAdapter generated, the visibility of the encapsulated Connection object is set to private. For the calling code to specify its own Connection object, the visibility of the Connection property has to be made public. This can be done by setting the ConnectionModifier property of the TableAdapter to public.