Accessing Data Using ASP Forms

You might have noticed a certain fairly consistent pattern when accessing data in Active Server Pages (ASP). This pattern is similar to the examples in Chapter . First a recordset is created, and then code something like the following is written within the ASP file:

<TD align="right">

<%=rs("Cost")%> <lTD> <lTR>

rs.MoveNext

Wend

This kind of code poses a couple of possible problems. First and foremost, the HTML code developed by the user interface designer is all mixed up with the code developed by the database designer. If the same person is doing both jobs, as is common on smaller sites, this overlap isn't a great handicap. However, when the application design task is divided between interface designers using HTML and database designers using Microsoft Visual Basic Scripting Edition (VBScript), difficulties often result. For example, during the development of a large application, it's possible that the user interface and the database design can be in flux at the same time. A source code tracking tool can help minimize this conflict, but such a tool could delay one developer while the other is doing work on a single file with both types of code inside.

A second problem is just plain silly, but I've caused it myself more times than I care to count. During the initial development of a large project, perhaps once a week, rather than following the pattern shown earlier, I write code something like this:

<TD align="right">

<%=rs("Cost")%> <lTD> <lTR>

Wend

The difference between this snippet of code and the previous one is subtle and will be obvious only when you run the page: it is, of course, the lack of code to move to the next record. This one missing line means that the page will never actually be displayed, because the predicate of the while statement (rs.EOF <>

True) will always be True and so the program will loop—at least until you stop Internet Information Services (IIS) or until the page times out. ADO.NET eliminates the problem of forgetting the record navigation statement by having the Read method of a DataReader object also navigate to the next record and then return a code indicating whether the navigation was successful. Thus, the ASP.NET example from Chapter 8 (using C#) is as follows:

<TD align="right">

<%=dr.GetDecimal(1).ToString("C")%> </TD>

In this ASP.NET example, dr.Read actually reads the next record and navigates through the DataReader at the same time. This change alone would save me one or two reboots a week.

Tip In the preceding code snippet, I use the efficient GetString method of the DataReader. There are many different Get methods to obtain the variable types supported. An alternative is to use syntax such as dr["FieldName"] or dr.GetBoolean(dr.GetOrdinal("BoolFieldName")). The problem with the dr["FieldName"] syntax is that the returned value is an object and so must be cast to the correct type. In this example, I know the field ordinals already, and so by calling GetString, I save a field name lookup.

0 0

Post a comment