f you are like me, you have already broken some of your New Year’s resolutions. As ASP programmers, however, it is time we made some resolutions to code better, more efficiently, and with performance in mind. Here are some resolutions I hope you will adopt and stick to.

Always Use “Option Explicit”
The single most common reason for ASP programmers pulling out their hair is the absence of the Option Explicit statement at the top of every ASP page. This requires you to declare a variable before using it in code. When it is not present, any variable found in your code will be assumed to be a valid variable?even a variable that you mistyped in a hurry. And that’s where the problem lies: debugging a page that you know is correct but does not work properly. Can you see what’s wrong with the following piece of code?

‘ – Get the Employee SalarycurEmployeeSalary = 48000′ – Calculate a nice 15 percent bonus on top of itcurBonus = curEmployeeSalary * 0.15′ – Add the bonus to our salarycurEmployeeSalry = curEmployeeSalary + curBonus’ – Now, proudly present the total figure to the ‘ — Employee who is waiting for this figure.Response.write FormatCurrency(curEmployeeSalary,2)

Guess what is output from the above lines of code. You expected it to calculate 15% bonus on a $48,000 salary thereby totally to $55,200. However, what is output is the plain old salary $48,000 with ZERO bonus. What happened?

A small typo. The third line of code (ignoring the comment lines) added the bonus and salary to a variable called curEmployeeSalry?Salry, not Salary. A small mistake, but when the Option Explicit statement is not used, the ASP compiler that is chugging along interpreting/compiling your code stops in its tracks and says: “You need me to add the two values and place it in a brand new variable called curEmployeeSalry. I will create a brand new variable for you.” And that’s what it does. It creates a brand new variable and the figure 55,200 is still sitting in the variable curEmployeeSalry, while the variable curEmployeeSalary was never modified.

If you had placed the statement Option Explicit at the top of the above page, it would never complete its execution. This would give you a run time error “Variable undefined” pointing to the variable that is misspelled.

So get with the program! Always declare your variables before using them, and force this discipline by using the “Option Explicit” statement.

<% Option Explicit %>

Never Place an OBJECT in a Session/Application Variable
Do you like using session variables? Are you fond of placing any and every value within a session variable? That’s okay, but please be careful. Never place an OBJECT within a session variable. How do you know if you’re doing this? Check your code. If it begins like this:


Set Session(“variablename


you are placing an OBJECT within a session variable. (An object always needs a SET statement for assignment?at least in all current versions of ASP.)

For example, you may have created an ADO recordset object or connection object and want to store it in a session variable so that you do not have to create it again, but can reuse the same object over and over again in your session. You are effectively crippling the Web server by doing anything like this. Why? The key words here are thread affinity and serialization.

Placing an ADO connection object in an application level variable is easy:

Dim objCONNSet objCONN = Server.CreateObject(“ADODB.Connection”)objCONN.Open “Your connection string here”‘ – place it in an application variableApplication.LockSet Application(“objCONN”) = objConnApplication.Unlock

Using it later on in your ASP page is also very easy:

Dim strSQL, objRSStrSQL = “Select * from Customers”Set objRS = Application(“objConn”).Execute (strSQL)

If you have stored an ADO connection object in an application level variable, you know that the variable is maintained till the Web server is shut down (the application ends). However, did you know that the variable is maintained on a specific thread? This is referred to as thread affinity. Any script that tries to access the variable has to either be on the same thread to make the call or must translate the call to the specific thread (a process called marshalling), which is a very expensive call to make. This results in lower performance.

If more than one ASP page is trying to make a call to a specific thread, they are placed in a row, one after the other to wait their turn before they can make the call. They are forced to run in a sequence. This is called serialization. Again, this results in performance degradation as your site serves more and more requests.

IIS is built to operate on multiple threads?a multi-threaded application. By placing objects in application level variables and forcing the Web application to wait for a specific thread to become active and run within it, you are forcing IIS to behave like a single threaded, inefficient application?effectively crippling its power.

The bottom line: Never place an OBJECT within a session variable. Learn more about this topic in Microsoft’s article “ INFO: Do Not Store STA Objects in Session or Application” Also, check out another great site LearnASP.com and its specific advice on ADO objects and session variables.

Note that the above piece of advice applies only to Single-threaded Apartment (STA) components, i.e., all Visual Basic COM components and ADO objects.

Use OLEDB Instead of ODBC
Another area where you can see immediate improvement is the technique you use to connect to your database. Consider moving from ODBC to an OLEDB connection.

If you are using an ODBC connection, you are probably using a System DSN or a File DSN to connect to your database. You can even use a DSNLess connection. You have a connection string that looks like one of the following:

DSN=DataSourceName; UID=userid; PWD=password;

Or

FILEDSN=FullpathtoFileDSN

Instead of using ODBC, use OLEDB. OLEDB is Microsoft’s COM-based interface to databases and other data sources. A full explanation of OLEDB is beyond scope for this little article, but you can find more details at Microsoft’s Universal Data Access site. OLEDB is also the underlying technology on which ADO rests on. Your ADO calls from an ASP page are first sent to OLEDB before they make their way to the next layer below. If you use an ODBC data source to your database, consider the layers the request and data have to travel through:

ASP – ADO – OLEDB – OLEDB Provider for ODBC – ODBC – Database

Most commonly used databases, SQL Server and Access included, now provide OLEDB providers that allow you to access the database directly from the OLEDB layer. You effectively bypass the ODBC layer by making a call using the OLEDB provider for the database. If you use OLEDB instead of ODBC, your data request and the data travel through one less layer:

ASP – ADO – OLEDB – OLEDB Provider for your database – Database

The result: OLEDB turns out to be faster than ODBC for the same database. In fact, in test results published in Wrox Press’ book ADO 2.0 Programmer’s Reference, OLEDB connections outperformed ODBC connections when used with server side cursors (the default in ADO) against both SQL Server and Access. Generally, you can expect a 10 to 30% speed improvement simply by changing over to OLEDB.

To use an OLEDB connection string with SQL Server, use the following as your connection string when you open the ADO Connection object:

StrConnString = “Provider=SQLOLEDB;” & _	“Password=YourPassword;” & _	“User ID=YourUserID;” & _	“Initial Catalog=YourDatabaseName;” & _	“Data Source=YourServerNameOrIPAddress;”

If you are using Microsoft Access, use the following as your connection string when you open the ADO Connection object:

StrConnString = “Provider=Microsoft.Jet.OLEDB.4.0;” & _”Data Source=FullPathToYourMDBFile;” & _”Persist Security Info=False;”

Remember to fill in the appropriate places within the connection strings before using it in your code. Here is a trick to quickly and easily generate your connection string if you already have the latest ADO or Microsoft Data Access Components (MDAC) installed on your machine.

• On your Windows 98/NT/2000 desktop, right click and Select New, Text Document.
• Change the name of the document from the default that Windows provides to “Sample.udl” (without the double quotes). If the system warns you that changing the extension is not recommended, select yes to proceed.
• Double click on the UDL file to bring up the “Data Link Properties” wizard.
• First, click on the “Provider” tab and choose the OLEDB provider of your choice. What you can select will depend on what OLEDB providers are installed on your machine. If you plan to use this on your Web server, make sure you are performing these steps on your Web server, or make sure it has the right OLEDB providers installed. OLEDB providers are included as part of the MDAC.
• Click Next to set the connection properties. Provide a user name and password if required. If you wish to include the password within your connection string, click the ‘Save password’ option if available.
• Finally, click the Test Connection button to make sure that your connection string works. Click OK to close the wizard.
• Right click on the UDL file on your desktop and open it with Notepad. The UDL file is a very simple text file. The last line in the file is your entire connection string, and usually begins with the word “Provider.” Copy and paste this line into your ASP page and you are all set.

Note: OLEDB is only marginally faster than ODBC if you are using a client-side cursor?a disconnected recordset. However, marginal is better than nothing!