Why relative filespecs may not work in ASP
Use ADO's native OLEDB drivers instead of ODBC
Generate accurate ADO RecordCount values in ASP
Use a single ADO connection to reduce ASP server load
Register WSC scripts before using them in ASP
Obtain a header list with ASP's ServerVariables collection
Create Visual InterDev 6.0 ASP code templates
A caveat when using ASP's Response.Redirect method
Simplify loading stored values via ASP
Convert ADO fields to XML tags without errors
Syntax requirements for integrating XSL into ASP and HTML
Configure IIS from DOS in Windows 2000
Cumulative patches for IIS 4.0/5.0/5.1 released at Microsoft
How to determine which version of the .NET Framework you're running
Even though the helpfile states you can use relative directory paths with FileSystemObject objects, you probably encountered an error if you tried to use them in an ASP path. That's because the directory that contains the ASP page doesn't become the current directory, as far as the FileSystemObject is concerned. To illustrate, run the following VBScript code in an ASP page:
Set FileObject = Server.CreateObject
CurrDir = FileObject.GetAbsolutePathName(".")
response.write "Using CurrDir: " & CurrDir & filespec & "<br>"
if FileObject.FileExists(filespec) then
response.write "[CurrDir] File Found<br>"
response.write "[CurrDir] No File found<br>"
response.write "Using MapPath: " & Server.MapPath(filespec) & "<BR>"
if FileObject.FileExists(Server.MapPath(filespec)) then
response.write "[MapPath] File Found<br>"
response.write "[MapPath] No File found<br>"
Set FileObject = Nothing
Submitted by: Michael Harris
When you create an connection string, ADO gives you a choice
between indicating a data source driver as either a Driver, as in
or a Provider, such as
However, when you use the first option, ADO uses older ODBC drivers to connect to the data source; whereas the second form uses OLEDB, which is ADO's native data access interface. For this reason, you should use the Provider option whenever possible. Such native OLEDB drivers exist for SQL Server, Index Server, Site Server Search, and
Oracle, among others.
DOM. For example, IE 4.0 + browsers include the document.all collection, while NN4.0 + browsers support the document.layers collection. If one of these objects is null, then your code can infer that the client is the other browser type. For example, the following script displays the boolean results of each test when you load a Web page:
var nav4 = !(document.layers == null)
var iex4 = !(document.all == null)
alert("Nav: " + nav4 + " IE4: " + iex4)
As you can see, the first expression sets the nav4 variable equal to the opposite of document.layers==null. So, if you view this page in an IE 4+ browser, document.layers is null, and the entire expression evaluates to false.
As you know, the ADO RecordCount property returns the number of records in an ADO recordset. Of course, in several instances, this property also returns a -1 instead. The value RecordCount returns depends on the recordset's cursor type: -1 for a forward-only cursor; the actual count for a static or keyset cursor; and either -1 or the actual count for a dynamic cursor, depending on the data source.
You may be surprised to learn that RecordCount will be -1 for recordsets created with the Execute method from a Connection or Command object. That's because this method generates a forward-only recordset, which, as we mentioned earlier, returns -1.
As an example, enter and run the following procedure in a
standard ASP page. When you open it, the page displays -1
for the recordset based on myConRst, and 6246 for myKeyRst.
Dim myConn, myComm, myConRst, myKeyRst
sConnection = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=D:\Microsoft Visual Studio\VB98\Biblio.mdb"
Set myConn = Server.CreateObject("ADODB.Connection")
Set myKeyRst = Server.CreateObject("ADODB.Recordset")
myComm = "Select * From Authors"
Set myConRst = myConn.Execute(myComm, , 1)
myKeyRst.Open myComm, myConn, 1
>From Connection: <%=myConRst.RecordCount%><BR>
>From Recordset: <%=myKeyRst.RecordCount%>
Set myKeyRst = Nothing
Set myConRst = Nothing
Set myConn = Nothing
If you need to execute multiple SQL statements on a single database in a single ASP page, it's often wise to open a single Connection and reuse it multiple times. Doing so reduces the number of times the server must open and close the same database, which can significantly increase the server's load. To use a single connection, create the
database Connection at the beginning of the page, then destroy it at the end. When you Execute a SQL statement, whether it returns a Recordset or not, specify the active Connection. Here's an example:
strDSN = "DSN=database;UID=username;PWD=password"
Set conn = Server.CreateObject("ADODB.Connection")
strSQL = "select column from table"
Set rsResults=conn.Execute(strSQL, , 1)
if not rsResults.eof then
temp = rsResults("column")
temp = "No Results"
'close the Recordset, but leave the Connection open
strSQL = "delete from table where column=123"
conn.Execute strSQL, , 1
'Done executing SQL statements at this point, so close the Connection.
set rsResults = Nothing
set conn = Nothing
Submitted by: Brian Coverstone [firstname.lastname@example.org]
The Windows Scripting Component is a great tool that let's you
create COM components for use in ASP pages. What's more, you can
you create a WSC component, however, you must register it before
you can use it in an ASP page. To do so, open Windows Explorer and
right-click on the WSC file you just created. Select Register from
the shortcut menu. To create an object variable based on the
new script object, use code similar to
Set objXMLCreate = Server.CreateObject("MyScriptObj.WSC")
At this point, you're free to access any of the object's methods
The SeverVariables collection contains all kinds of information
about the calling client and the server. For instance, you can
determine a visitor's browser type with the HTTP_USER_AGENT
variable. Or, you can use HTTP_REFERER to determine the referring
Internet address. Not all browsers support the same headers,
however. To see a quick list of the headers supported within a
browser, run the following code.
For Each var in Request.ServerVariables
TD><B>" & var & "</B>
.Write("<TD>") & Request.ServerVariables(var) _
Instead of retyping the same code lines on virtually every ASP
page that you create in Visual InterDev 6.0, simply open
Program Files | Microsoft Visual Studio | VIntDev98 | Templates |
Web Project Items | New ASP Page.asp file, and then enter the
code that you want duplicated, i.e. included files, titles,
metatags. Save your work, and any new ASP page that you create
will contain the new code.
Submitted by: Will Smith
When ASP encounters the Response or End methods, it immediately halts script execution in both the GLOBAL.ASA file and in the application page. As a result, ASP won't execute any script that follows the Redirect method. Instead, it either ends the session or begins processing the new page. For this reason, you should always make the Redirect method the last call in any script.
When loading an <OPTIONS> list from a database table, it's much
easier to call a procedure that uses process parameters. This way,
you can use the same procedure for several different operations. For
example, suppose you want to fill a Listbox with a list of animals.
In addition, you've set up several checkboxes on a Web page that let
the user simply view the list, or load the list with one of the
animals already selected. The following example shows how you might
process the resulting page. (To save space, we hard-coded the two
<!-- #include File="DBConnect.Asp" -->
<SELECT name=Atype size= 5>
chkMode = 2 'or Request.Form("chkMode")
Sub fillOptionList(myMode, optionValue)
set rsAnimal = CreateObject("ADODB.recordset")
.Open "tblAnimals", strDB, adOpenStatic,,adCmdTable
Do While Not .EOF
Select Case myMode
strSelected = ""
If optionValue = rsAnimal("Animal") Then
strSelected = " SELECTED"
strSelected = ""
Response.Write("<OPTION" & strSelected & " VALUE=" _
& rsAnimal("ID") & ">" & rsAnimal("Animal") & "</OPTION>")
Set rsAnimal = Nothing
For the OPTION elements, this code produces output HTML like this:
<SELECT name=Atype size= 5>
<OPTION SELECTED Value=4>Snake</OPTION>
Submitted by: Faisal Ladak
XML tag names can't contain several special characters or spaces. Therefore, when you use ADO field names as XML tags, make sure to rename the fields, if necessary, in the SQL statement. For example, if you use the following SQL statement:
Select [Employ ID], Name FROM Employees
and then use XMLDOM to convert the recordset fields into XML, the XML document will generate an error. That's because XMLDOM's creation methods convert the [Employ ID] fieldname into <Employ ID>. However, the space is an invalid character. To avoid this error, use an alias name in the SQL string, such as:
Select [Employ ID] AS EmployID, Name FROM Employees
Since an XSL stylesheet is an XML document itself, its markup must
conform to XML grammar rules. Most notably, you must ensure that
you close all tags. Since HTML is considerably more forgiving in
this regard, make sure that the markup in XSL sheets will
successfully parse. For example, to use <BR> to express a line
break, you must enter <BR> instead. To read more about the
W3's recommendation for XHTML, which addresses this issue, see
Windows 2000 provides a wealth of IIS management and administrative scripts that you can use from the DOS command prompt. Among other things, you can search your Web server for a virtual Web site, display a tree of the structure of your IIS server, create Web sites and virtual directories, start and stop services, and more. Take a look at the following URL for more information:
As you know, keeping your Web server up-to-date with the latest patches and security fixes can be a real challenge. Fortunately, Microsoft recently released a cumulative patch that saves you a lot of trouble. For IIS 4.0, the patch includes all fixes released since Windows NT 4.0 Service Pack 6a. For IIS 5.0 and 5.1, the patch includes all fixes released to date. Period. Navigate to the following URL to download and install this critical product update:
Since the .NET Framework itself is just a collection of classes and structures, you might wonder where to look to determine the exact version, including installed service packs, of the Framework you've got. This is especially true when you inherit responsibility for a machine running .NET. Here's where to look:
For Windows 2000 and XP, you need to run the .NET Framework Configuration MMC snap-in. On Windows XP, this is tucked away under Administrative Tools on the Start menu. For Windows 2000, you'll have to manually add it to a running instance of MMC. In either case, choose Help | About from the snap-in menu, and you'll see which version you've got to work with.
For Windows 98, Me, and NT 4.0, you'll need to download this snap-in from Microsoft, since it isn't installed by default. Get it at http://download.microsoft.com/download/platformsdk/Install/1.2.0/W9XNT4Me/EN-US/IMMC.EXE.