Working with ADO.NET

ADO.NET is the main data access system and protocol that Visual Basic .NET uses. As we've already mentioned, it uses a disconnected data architecture, which means that the data you work with is just a copy of the data in the data in the actual database. There are a number of reasons that Microsoft chose this disconnected data architecture; in traditional client/server applications, you get a connection to a database and keep it open while the application is running. However, maintaining those connections takes up a lot of server resources, and, of course, when you want to migrate to the Internet, you have to maintain disconnected datasets instead of maintaining direct and continuous connections.

Tip

If you need a continuous connection to a database—as when other applications are making changes to the same database that you need to be appraised of (you might be selling theater tickets, for example)—you should know that you actually can use traditional ADO (instead of ADO.NET) objects in Visual Basic .NET. To work with these objects, you use the Project|Add Reference menu item, click the COM tab in the Add Reference dialog, and select one of the ADO libraries. You're then free to use ADO objects in your code.

To store the data you work with in your application, you use datasets, which represent a sort of data cache of records. (It would be impractical to access the database each time you need a new record.) The data in the dataset is usually a much-reduced version of what is in the database. However, you can work with it in much the same way you do the real data. While you are doing so, you remain disconnected from the database, which lets it perform other tasks. You will probably need to update data in the database, and using data adapters, you can perform update operations on the dataset, and these can be written through to the underlying database.

Datasets are really just passive containers for data. To actually get data from a database and write it back, you use data adapters. A data adapter contains the instructions for populating a single table in the dataset and updating the corresponding table in the database. The instructions are methods that encapsulate either SQL commands or references to stored procedures.

Note that because a dataset exists only locally, it does not necessarily reflect the current state of the database. Although a dataset acts as a cache for data drawn from a database, the dataset has no actual direct relationship with the database. The dataset is a container; it is filled by SQL commands or stored procedures executed from a data adapter. If you want to see the latest changes made by other users, you can refresh the dataset by calling the Fill method.

How does the data actually get from the data source to the dataset? ADO.NET uses XML as the format for transferring data. Similarly, if data needs to be saved, which Microsoft calls "persisting," it is stored as XML, the data description language developed by the World Wide Web Consortium (W3C; see www.w3.org). This is handy in some cases; for example, if you have an XML file, you can use it as you would any data source and create a dataset from it. You don't have to know how to use XML yourself, of course. Visual Basic .NET will handle the details for you.

Tip

For more on XML and how to write it, see the Coriolis HTML Black Book.

One of those details is that ADO.NET needs some way of defining the structure of a dataset using XML. The actual structure—that is, what tables, columns, data types, constraints, and so on are in the dataset—is set up with an XML schema. Like XML, XML schemas have been developed by the W3C (although Microsoft uses a proprietary version of XML schemas). They're used to describe the format of an XML file so an application can verify that the XML data is valid. However, that's not usually something you have to worry about directly, because the Visual Studio .NET tools will generate and update schemas as needed, based on what you do in visual designers. To see what such schema look like, take a look at "Examining Dataset Schema" in this chapter.

Tip

For all the details on XML and XML schema, see www.w3.org/TR/REC-xml and www.w3.org/TR/xmlschema-0/, respectively. These are the official W3C documents on these topics.

As we've seen while working with data connections, data adapters, and datasets, ADO.NET handles data with a series of objects. It's going to crucial to know these objects and what they do in the coming chapters, so I'll go over them now in overview to give us a good foundation in ADO.NET.