Quick Index: ASP & VBScript, JavaScript, ActiveX Data Objects

ASP/VBScript Top

1. Try not to mix VBScript with HTML too often, since the server has to perform a context switch every time it starts a script block indicated by "<%" and every time it leaves a script block, indicated by "%>".
   
   e.g the following code does 6 switches:
<%
   GetUserDetails()
%>
<BR>
Welcome back:<%response.write(session("myname"))%>
<BR>
You Have Been Away for:<%response.write(session("away"))%>Hours
<BR>

Whereas the following code only does one and has the same result: <%
   GetUserDetails()
   response.write("<BR>Welcome back:"+session("myname")+ _
   "<BR>You Have Been Away for:" + session("away")+"Hours<BR>")
%>


2. Do not buffer up output within a loop that is to be written to the final document in temporary strings, since this can be very slow. It is much more efficient to use the "Response.Write" routine to output data as soon as it is becomes available.
   
   e.g. the following VBScript:
dim str
for x=0 to 100
   str=str+"X="+cstr(x)+vbcrlf
next
response.write(str)
would be better rewritten as: for x=0 to 100
   response.write("X="+cstr(x)+vbcrlf)
next


3. A single "response.write" statement should be used as opposed to having many lines of code outputting each line via a separate call. Note: readability of your script can be preserved by using newline characters and the continuation marker "_", as shown in the following example:
   
   Response.write("<TABLE>")
   Response.write("<TR><TD>First Column")
   Response.write("<TR><TD>Second Column")
   Should be re-written as:
   Response.write ( "<TABLE>" + _
      "<TR><TD>First Row" + _
      "<TR><TD>Second Row" )
   
   
4. If you also wish to preserve readability in the HTML source of the final document, then you need to send extra carriage returns back to the browser as shown in the following statement:

Response.write ( "<TABLE>" + vbcrlf + _
    "<TR><TD>First Row" + vbcrlf + _
    "<TR><TD>Second Row" )


5. By default, output buffering is switched on. This allows you to use the "Response.Flush" routine to force display of the document built up to this point. This can be useful for pages that take a long time to load.
   
   
6. Make sure you comment your code. The use of comments does not have a significant impact on performance since all the server side VBScript is removed before a page is returned to the browser.

ActiveX Data Objects (ADO)Top

1. The Microsoft COM object ADO should be used for all database access via ODBC connections. All database related code should be encapsulated within Visual Basic COM objects.
   
   
2. If available, make use of Microsoft Transaction Server to handle the running of your COM objects. Ensure the timeout of your equivalent Packages is set to a suitable value, since the default timeout is 5 minutes. Recommend setting it to a similar value to your IIS server’s ASP timeout value.
   
   
3. Convert dates to and from your database into a general purpose format (use the Database.ConvertedDBDate function from CommonADO). This will ensure consistency and compatibility across alternate databases. Note: without this function a blank date would get returned as "31/12/1999 23:59:59" via the current Ingres ODBC driver.

JavaScript Top

1. Ensure that any JavaScript that depends on objects dynamically created via server side VBScript, actually check for their existence, prior to attempting to use the objects. E.g. if a database failure stops an option list being built, we do not need to see additional JavaScript syntax errors.
   
   The following code shows an example of checking for the existence of an object named "frm.hols", prior to invoking a function that would act on it:
if (frm.hols)
    HighlightHols();


2. Do not use too many comments. Unlike VBScript which gets removed prior to a page being returned to the browser, all JavaScript remains, since it is required by dynamic client side behaviour. As a result too many comments will increase the time it takes to load a page. Although this effect is not great, it should be noted. Another effect is that your well formatted and commented JavaScript becomes easy for people browsing your site to view and use for their own purposes.
   
   
3. Using the "++" and "- -" operators results in faster code than the more readable versions. E.g. x=x+1; is slower than x++;
   
   
4. Remember that JavaScript is case sensitive. This applies to function calls, local variables and document objects. Many errors can occur from a simple mistyped object name.
   
   
5. An easy mistake to make. When comparing values, be sure to use the "==" operator as opposed to the "=" operator. Strange behaviour may result, which is very difficult to debug.
   e.g. the following statement is wrong, since it actually sets the value of x to zero and the condition evaluates to false, yet it will not raise any compilation errors.
   
   

   if (x=0){alert("zero value found");}

   The correct statement is show below:

   if (x==0){alert("zero value found");}