Home arrow ADO.NET arrow Page 3 - Easing Transition From ASP and ADO to ASP.NET and ADO.Net Part 1/2
ADO.NET

Easing Transition From ASP and ADO to ASP.NET and ADO.Net Part 1/2


You shouldn't have to learn six objects beginning with the word "Data" to start using ADO.NET. More importantly, you shouldn't have to depend on learning a brand new object model for Microsoft's DataGrid object to customize the HTML you're sending to the end user. In this article Ruffin compares classic ASP and ADO to Microsoft's ASP.NET and ADO.NET technologies, easing the transition to ADO.NET for current ADO developers.

Author Info:
By: Ruffin Bailey
Rating: 5 stars5 stars5 stars5 stars5 stars / 67
March 21, 2002
TABLE OF CONTENTS:
  1. · Easing Transition From ASP and ADO to ASP.NET and ADO.Net Part 1/2
  2. · Making the connection
  3. · Where did my RecordSet go?
  4. · Creating Column Headers
  5. · Conclusion

print this article
SEARCH DEVARTICLES

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.
blog comments powered by Disqus
ADO.NET ARTICLES

- Datasets in Microsoft.Net
- Latest Developments in the .Net World
- Introduction to .NET
- Automatic Generation of Single Table SQL Sta...
- Data Access in .NET using C#: Part 1
- All You Need To Know About ADO.NET: Part 2/2
- All You Need To Know About ADO.NET: Part 1/2
- Easing Transition From ASP and ADO to ASP.NE...
- A Practical Comparison of ADO and ADO.NET

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials