This documentation is archived and is not being maintained.

Creating Data Applications with Visual Studio 

This introduction presents a high-level overview of the processes involved in creating applications that work with data. The information here deliberately skips over many details and is designed as a source of general information and a jumping-off point to the many other Help pages associated with creating a data application.

As you develop applications that access data in Visual Studio, you will have different requirements. In some cases, you might simply want to display data on a form. In other cases, you might need to devise a way to share information with other applications or processes.

The underlying data architecture used to create applications in Visual Studio is ADO.NET. No matter what you do with data, there are certain fundamental concepts that you should understand. You might never need to know some of the details of data handling — for example, you might never need to programmatically create a database, but it is very useful to understand the basic concepts of ADO.NET, as well as the data tools (wizards and designers) available in Visual Studio.

The overall task of working with data in an application can be broken down into several top-level processes. For example, before you display data to a user on a form, you must first connect to a data source (possibly a database), and then fetch the data you want to display. Once you bring this data into your application, you may need somewhere to temporarily store it, such as a DataSet object.

A typical data application will utilize most of the processes illustrated in the following diagram:

The Data Cycle
Data Cycle graphic

As you create your application, think of the task you are trying to accomplish. Use the following sections to assist in finding the Visual Studio tools and .NET Framework objects that are available to you.


Keep in mind that wizards are available to simplify several of the processes displayed in the diagram above. For example, running the Data Source Configuration Wizard provides your application with enough information to connect to data, create a typed dataset to receive the data, and bring the data into your application.

To quickly see how Visual Studio helps you in developing data applications, see Walkthrough: Creating a Simple Data Application.

Connecting to Data

To bring data into your application (and send changes back to the data source), some kind of two-way communication needs to be established. This two-way communication is typically handled by a connection object (for example, a SqlConnection) that is configured with a connection string, the information it needs to connect to the data source. Visual Studio provides several tools to assist in creating connections that can be used by your application. For more information on connecting your application to data, see Connecting to Data in Visual Studio.

To learn how to connect your application to data, complete the procedures in Walkthrough: Connecting to Data in a Database.

Preparing Your Application to Receive Data

If your application uses a disconnected data model you need to temporarily store the data in your application while you work with it; a dataset (an in-memory cache of data) simplifies the process of working with data until you reconnect with your data source. Prior to querying your data, you create a dataset to receive the results of a query. The dataset is created with the same shape (schema) of the returned data.


An application that uses a disconnected data model will typically connect to a database, run a query bringing data into the application, disconnect from the database, and then manipulate the data "offline" before reconnecting and updating the database.

For more information on creating typed datasets in your application, see Preparing Your Application to Receive Data.

To learn how to create a dataset, complete the procedures in Walkthrough: Creating a Dataset with the Dataset Designer.

Fetching Data into Your Application

Whether your application uses a disconnected data model or not, you need to be able to fetch data into your application. You bring data into your application by executing queries or stored procedures against a database. You execute queries and stored procedures using TableAdapters and command objects. For more information on creating and editing queries, see How to: Create TableAdapter Queries and How to: Edit TableAdapter Queries.

For more information on loading data into datasets, and executing queries and stored procedures, see Fetching Data into Your Application.

To learn how to load data into a dataset, complete the procedures in Walkthrough: Displaying Data on a Form in a Windows Application and examine the code in the form-load event handler.

To learn how to create and execute a SQL query, see How to: Create and Execute an SQL Statement that Returns Rows.

To learn how to execute a stored procedure, see How to: Execute a Stored Procedure that Returns Rows.

Displaying Data on Forms in a Windows Application

After bringing data into your application, you will typically display it on a form for users to view or modify. Visual Studio provides the Data Sources Window, where you can drag items onto a form to automatically create data-bound controls that display data. For more information on data binding and displaying data to users, see Displaying Data on Forms in Windows Applications.

To learn how to present data to users in Windows Forms, complete the procedures in Walkthrough: Displaying Data on a Form in a Windows Application, paying particular attention to the process of dragging items from the Data Sources window.

Editing Data in Your Application

Once your users have been presented with data, they will likely modify it by adding new records and editing and deleting records prior to sending the data back to the database. These modifications are made by manipulating the individual DataRow objects that make up the tables in a dataset. For more information on working with the data once it is loaded into your dataset, see Editing Data in Your Application.


If you create forms by dragging items from the Data Sources window, much of the changes to data are automatically handled through the data-bound controls. When you edit the values in the controls, the new values are automatically written to the dataset. You can add or remove records by clicking the Add New or Delete button on the BindingNavigator control.

To learn how to add new records into a dataset, see How to: Add Rows to a DataTable.

To learn how to edit existing records in a dataset, see How to: Edit Rows in a DataTable.

To learn how to delete records from a dataset, see How to: Delete Rows in a DataTable.

Validating Data

When making changes to data, you will typically want to verify the changes before allowing the values to be accepted back into the dataset or written to the database. Validation is the name of the process for verifying that these new values are acceptable for the requirements of your application. You can check values in your application as they are changing. For more information, see Validating Data.

To learn how to add data validation to your application, see Walkthrough: Adding Validation to a Dataset.

Saving Data

After making changes in your application (and validating those changes), you typically want to send the changes back to the database. If you are using datasets and a disconnected data model, then you should check for concurrency violations. (This term refers to a situation in which data in a database has changed since you originally loaded it into your application and now contains newer values than those in your application). You may also want to update several tables at once, in which case you may want to use a transaction. For more information on sending updated data back to a database, see Saving Data. For more information on saving data in a transaction, see How to: Save Data using a Transaction.

To learn how to send updated data from a dataset to a database, complete the procedures in Walkthrough: Saving Data to a Database (Single Table).

See Also