Easing Transition From ASP and ADO to ASP.NET and ADO.Net Part 1/2 - Where did my RecordSet go?
(Page 3 of 5 )
There's no RecordSet equivalent in ADO.NET. ADO.NET prefers to employ a disconnected data architecture where you fill up miniature copies of your database with data and then work directly with these miniature copies. These copies are stored in DataSets and are filled by DataAdapters. They can contain DataRelations and all sorts of other overhead, as well as new objects whose data models we don't need to deal with to simply display the data.
What you might not realize is that not all ADO.NET objects use the disconnected data architecture. ADO.NET provides an object that opens a connection to a data source and reads the data over the open connection while you're working with it. This object then needs to be closed to free up the original connection to the database, and all of this is in concert with a data provider (like SQLOLEDB for example). Sounds like a RecordSet object to me, right?
This object is actually called the DataReader, and it provides us with a subset of what we used to get with ADO's RecordSet object, namely an object with adOpenForwardOnly and adLockReadOnly as our only options. Although the disconnected data architecture with miniature copies of subsets of databases is preferable in many conditions, one thing Microsoft realized is that what we weren't going to want to do is make a copy of our entire database for each user that connects to it and requests to view our data.
The DataReader object allows us to take all data that matches our command (in this case, an SqlCommand object) and instead of creating the overhead needed to store this data in a "mini-database", we're allowed to step-in and use the data stream directly. This is exactly what we've been doing in classic ASP for years.
If we want to move forward and backwards through out data and also update the data that the user is currently viewing, then we'll need something more powerful, however forward-only, read-only operations are the DataReader's specialty.
Let's look at how we can create an SqlDataReader object by using the ExecuteReader method of an SqlCommand object:
SqlDataReader readPubs = cmdTemp.ExecuteReader();That's all there is to it... we've finally found our RecordSet equivalent in ADO.NET!
[Note] Each of the three pages contained in the support material contain the same code up to one specific point in the file. Whether we hardcode output, dynamically create our own DataGrid replacement, or use the Microsoft DataGrid object, we still create the SqlDataReader the same way.
[End Note]But I don't wanna use the DataGrid!At this point, most tutorials regarding DataReaders will show you how to bind your new DataReader object to a DataGrid and will use the ASP:DataGrid object in HTML code. The DataGrid would insert a fairly plain table into our HTML code. The table produced by this DataGrid would have very little formatting, less than ideal spacing in the dynamically generated HTML code, and would leave you with a whole new object model to learn before you could fully customize the HTML code you're sending to the user.
Let's take our DataReader object and send it through the same logical steps we would have used in a well-done classic ASP page. I'm going to take the results from the logic in this code and add it to a string object I've created, rather than write it to the browser with the response object piecemeal.
StrReturn will include the entire HTML markup for the table I'm about to create. In my opinion, this is one step better than pure "spaghetti code", where the HTML is interspersed between <% and %> tags. By doing all our work with one string, we're only one call to Response.Write away from inserting our new object, which makes for cleaner code. It'll also speed our transition to the codebehind method in part two of this article.
Next: Creating Column Headers >>
More ADO.NET Articles
More By Ruffin Bailey
