Friday, September 26, 2008

asp getrows() to asp.net

All of the code for this post is available upon edit.

Entire contents of this post were taken from
a dotnetjunkies article

Introduction

I believe .NET is the most exciting new development platform to date, with cumulative features surpassing many others as a whole. Migrating your legacy ASP code can be a daunting task given that you're learning as you go, but if you had some perusal of the framework it'll be a little less cumbersome. Of course with .NET, the ability to co-exist with legacy ASP code is fine, and you can even port in legacy code through the help of the exposing the legacy ADO components. But anyone serious about .NET would benefit themselves in taking full advantage of .NET and all it has to offer.

As you begin to delve deeper into the means of migrating your old code to .NET, you may run into a few stumbling blocks, and more so when you embark towards C# in particular, because of syntax differences and some VBScript/ASP coding methods you may have been accustomed to. In any event, one feature I have found to be missing in sorts in migration is the simple ADO method of GetRows which copies your data results into an two-dimensional variant array in the form of recordset.GetRows(Rows, Start, Fields).

In .NET however this exact method is not to be found, or is it? Well it is…kind of. Now, most people learning .NET upon first view might see a general template driven approach in which applications can be developed. They learn about DataGrids, Web controls, code-behind, data readers, and so on, so this all may give the immediate impression of developmental building blocks without much precise control of one's code. Well nothing could be further from the truth. Replicating GetRows in .NET is easier than you think and it gives you precise control in the detail of your data and its display. Having said that, one feature not available with this method is the implemention of the NextRecordSet feature, whereby multiple batch SQL statements can be consecutively run. Nevertheless, the .NET DataReader duplicates this functionality with Reader.NextResult(), but not within the context of this example.

This article at the very least will inform you about the DataTable object and how to use it.

To now get back on track, let's explore the classic ASP method of displaying a table of data with GetRows and then replicate it exactly in .NET.

The Old Fashioned Way

The code here shows how we can query a database and write out the columns and rows into a nicely formatted table.

The Code: Below I open a database connection, run my query and loop through the records with GetRows and display the results. To run the examples below as written you'll need to have the Pubs database available to you.

<%@ Language=VBScript %>
<%
Dim sqlStr

sqlStr = "Select lname As LastName, fname As FirstName, emp_id As ID, hire_date As [Hired On] from Employee"

'Open up the database connection
Set dbConn = Server.CreateObject("ADODB.Connection")
With dbConn
.Provider = "SQLOLEDB"
.ConnectionString = "Provider=SQLOLEDB;USER ID=sa;PASSWORD=;INITIAL CATALOG=Pubs;Data Source=(local)"
.Open
End With

Set rsDbConn = dbConn.Execute(sqlStr, adExecuteNoRecords)

If Not rsDbConn.EOF Then
GetrsConn = rsDbConn.GetRows()
End if

Response.Write ""
Response.Write ""

'Columns name loop
For c = 0 to UBound(GetrsConn,1)

Response.Write ""
Next
Response.Write ""

'Rows loop
For r = 0 to UBound(GetrsConn,2)

Response.Write ""
Response.Write ""
Response.Write ""
Response.Write ""
Response.Write ""
Response.Write ""


Next

Response.Write "
" & rsDbConn.Fields(c).Name & "
" & GetrsConn(0,r) & "" & GetrsConn(1,r) & "" & GetrsConn(2,r) & "" & GetrsConn(3,r) & "
"

'Close and clear our connections
dbConn.Close
Set rsDbConn = Nothing
%>


Again, this is standard to any ASP developer. Now as you'll see, you can do the exact same thing in .NET and explain that after.

Let's Do the Same Thing in .NET

<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>






<%=grTable.ToString()%>





Let's Explain

The first thing in our .NET code above is importing our Data namespaces to allow us to call our objects so we can connect to the data. Next we declare all our variables. We then set-up our database connection and call the DataAdapter to open and query our data source. Now within our called DatAdapter we expose our DataSet which is a disconnected storage container of the tables holding our data, and this can hold a lot of tables.

By means of our DataSet we are offered much control over our data presentation. The DataSet upon creation stores and exposes a collection of rows and columns or a DataTable object (which stores one in-memory table), with which we can manipulate and view our results, even updating, deleting, and inserting.

Now after I queried the database and filled the DataSet with the help of the DataAdapter, I exposed our DataTable object with GetRows - a DataTable declared variable object, and got some precise information on what it contains.

I wanted to know how many columns and rows there are and with the DataTable.Rows.Count and DataTable.Columns.Count I get that. Next, I use .NET's cool new string building method - the StringBuilder to build my table. It was filled with two loops - one loop for telling us the columns name by GetRows.Columns(c).ToString() method and another loop for our row information like so GetRows.Rows(x)(y).ToString(), whereby x indicates row number and y is column number.

Then I send out my results as a string to the tag below and that's it.

Conclusion

Here I have demonstrated a very simple and easy way of migrating your old GetRows code exactly over to .NET. You may at times simply employ many of the native .NET controls to display your data if you feel that'll be enough, but you may at times run into snags like I have and this was the only satisfactory way of displaying my data in the way I needed to.

So when it comes to migrating legacy code, .NET does it and more, and with so much more power, performance and class, and without compromising any flexibility whatsoever.

No comments:

Post a Comment