Chapter 13. ADO.NET Connection and Command Objects
In order to work with data, your application needs to be able to supply some important information. Among other things, you might need to provide answers to the following questions:
What data source do you want to use (SQL Server, Access/Jet, Oracle, DB2, and so on)?
Where is the data located (physical path or server name)?
How do you log in if security is involved?
Without this information, your application can't even find the data, much less use it. ADO.NET's Connection objects (specifically, OleDbConnection or SqlConnection) manage this information for you.
Before you can retrieve or manipulate data, you'll need to supply connection information. You can either create a Connection object explicitly or simply supply connection information in the form of a connection string and have ADO.NET generate a Connection object for you, as necessary. You can use the design-time ADO.NET components provided by Visual Studio .NET to create a Connection object for you, as well.
In this chapter, you'll investigate creating your own Connection object and also look into how and when you should create and destroy your Connection object. You'll also learn how to use the Command object provided by ADO.NET, in conjunction with the Connection object, to retrieve data.
As a reminder, when we refer to a Connection object, we're just simplifying matters. There are at least two different Connection objects available as part of ADO.NET: OleDbConnection and SqlConnection (basically, one for each ADO.NET namespace). If there are differences between the two types, we'll note them. If not, we'll refer to both objects generically as Connection. The same thing applies to Command objects, later in the chapter.
You'll need a Connection object in order to work with data. There's no way around it. Whether you create the connection implicitly or explicitly, it's there. You should think about keeping the connection open for as short a period of time as possible, every time you work with data.