Data Source Controls in ASP

Data Source Controls
In ASP.NET 1.x, you typically performed a data-binding operation by writing some data access code to
retrieve a DataReaderor a DataSetobject, then you bound that data object to a server control, such as
a DataGrid , DropDownList, or ListBox. If you wanted to update or delete the bound data, you were
then responsible for writing the data access code to do that.
ASP.NET 2.0 introduces an additional layer of abstraction through the use of data source controls. The
data source controls abstract the use of an underlying data provider, such as the SQL data provider or
the OLE DB data provider. This means that you no longer need to concern yourself with the underlying
complexities of using the data providers. Instead, the data source controls do all the heavy lifting for
you. All you need to know is the location of your data and, if necessary, how to construct a query for
performing CRUD (create, retrieve, update, and delete) operations.

SqlDataSource Control
The SqlDataSource control is the data source control to use if your data is stored in a SQL Server,
Oracle Server, ODBC data source, OLE DB data source, or Windows SQL CE Database. The
SqlDataSource represents a database connection that uses an ADO.NET provider. However, this has a
catch. The SqlDataSource needs a generic way to create the Connection, Command, and DataReader
objects it requires. The only way this is possible is if your data provider includes a data provider factory,
which has the responsibility of creating the provider-specific objects that the SqlDataSource needs in
order to access the data source.
As you know, .NET ships with these four provider factories:
❑ System.Data.SqlClient
❑ System.Data.OracleClient
❑ System.Data.OleDb
❑ System.Data.Odbc
These are registered in the machine.config file, and as a result you can use any of them with the
SqlDataSource . You specify the provider name as part of the SqlDataSource control declaration. Here
is a SqlDataSource that connects to a SQL Server database:

The next step is to supply the required connection string — without it, you cannot make any connections:


Once you have specified the provider name and connection string, the next step is to add the query logic
that the SqlDataSource will use when it connects to the database. The complete declaration of the data
source control is:

Now that you have the SqlDataSource control with all the attributes, the next step is to add a data-
bound control that uses the data from the data source control. In this case, a DropDownListcontrol is
used as the data-bound control:


Connection Strings from the Configuration File
In ASP.NET 2.0, Microsoft has tried to address the common shortcomings in the Web.config file with
ASP.NET 1.x. One such shortcoming is that there is not a well-defined location for storing connection
strings. Because database connection information is so frequently stored in the Web.configfile, you
now have an entirely new configuration section in that file, , specifically for stor-
ing the connection string information.
Although you can hard-code the connection string directly in the SqlDataSource tag (as shown in the
previous section), you should always place it in the section of the Web.config
file to guarantee greater flexibility and ensure that you won’t inadvertently change the connection
string, which minimizes the effectiveness of connection pooling. For example, add the below connection
string in the Web.configfile:

...

With the above connection string placed in the Web.configfile, you would reference it in the
SqlDataSource using the $ expression, as shown below: