IN THIS CHAPTER
Some of the fundamental questions that developers ask during system design are: Should the application persist its data somewhere? If so, where and how? Persisting, or storing, data for later use is such a core concept that many of us simply take it as a “given” when we write our applications. Whether we store state in a database, in an INI file, or in the registry, we are forced to employ design patterns ranging from simple data queries and record inserts, to complicated transactional programming and schema manipulation.
Visual Basic traditionally has had very rich support for implementing data storage, particularly with relational databases. Although in the history of Visual Basic it is a relatively recent “invention,” ADO (ActiveX Data Objects) is a cornerstone technology for allowing developers to abstract data storage concepts in their code. ADO has been extended into the .NET world with the System.Data, System.Data.Common, System.Data.OleDb, System.Data.SqlClient, and System.Data.SqlTypes namespaces. Collectively, the System.Data.* namespaces are often referred to as ADO.NET—a clear indication of its technical legacy.
In this chapter, we examine common programming tasks related to the storage and access of data, primarily with relational databases.
We'll begin by providing a brief introduction to ADO.NET and examining the several paradigm changes it brings. Then, we discuss how to connect to a database, issue SQL commands to a database, and work with stored procedures. Finally, we examine how to handle errors, work with transactions, and examine relational schemas.
After reading this chapter, you should have a firm grasp of the following:
Connecting to a database
Querying a database for data, and then processing the data that has been returned
Programming SQL commands in a transactional environment
3.147.67.48