Implement/TestMicrosoft ASP Coding Techniques

May 10, 2000, 9:00 a.m. to 11:30 a.m.

Jim Blizzard, Microsoft Consulting Services, PacWest District

E-Coding: ASP, SPROCs, and ADO

ASP: Active Server Page

SPROCs: Stored Procedures

ADO: ActiveX Data Objects

Parks’ latest version of its boat moorage permit site was reviewed. It includes a three-step application process in the following pages:

• WA State Parks’ Boat Moorage Permit information page
• Lists three steps of the application process
• Step 1 - retrieve user and boat information
• Step 2 - retrieve payment information and confirm order
• Step 3 - print temporary permit or, if transaction failed, display redirect to mail-in process

In order for the user to see the "Print temporary permit" page, the transaction had to be successful.

Each time the user presses the "Submit" button, CyberSource imposes a charge even if the transaction fails. Therefore, an agency may wish to consider limiting the number of failed attempts.

CyberSource is a synchronous processor. As such, it may take some time to pass a credit card through the system. Although users are usually willing to wait longer for credit card clearance than for other actions, an agency may wish to include code to prevent a customer from hitting the "Submit" button multiple times, thereby creating multiple orders. For example, the "Submit" button could be replaced with a message such as "Your transaction is being processed".

Data for Phase I of the project will be hand keyed to Parks’ Access database from the Sequel Server database.

The browser level is 800x600. If larger, the customer will have to scroll.

ASP allows dynamic production of HTML pages. If the browser can display HTML, it can display ASP-produced pages.

As a project becomes "big" an agency may want to develop pieces as COM components. ASP can be used to glue these together which helps to speed up the process. As a rule of thumb, "big" means lots of business logic (50-100 lines of ASP code per page).

• FrontPage is an excellent tool for creating layout. You can set fonts and drag cells around. However, beware of FrontPage 98. It tends to eat ASP code. FrontPage 2000 has corrected this problem.

• Use Include files for common functions. Then, the function needs only to be written once in the application. Although many books suggest these files be named with a ".inc" extension, the presenter recommends naming them ".asp". They also may have a ".htl" extension, but if the HTML has some ASP inside it, it MUST have a ".asp" extension.

• Place all Include files in a directory named "Include" or "Includes"

• Use Application variables for "constants" (e.g. $50 boat moorage fee or key value pairs required by CyberSource) that are used across pages. Define at top of page. Then, when the fee changes, it needs to be changed in only one place. Application variables are not static or constants so you can change the value of an application variable on the fly.

• NEVER put an object in a Session variable. Although the customer may have left the site, these variables remain for about 20 minutes. This can pose a memory/space problem.

• Whenever you create an object, set it to "nothing" on each page. This helps to free up memory.

• Use "On Error Resume Next/On Error Goto 0" around "sensitive" text, such as a server-create object, to protect it. Keep it around code only. In this way, you turn it on, create your object, check to be sure it’s an object, trap an error that may occur, handle the error around the sensitive part of the code code, then turn it off.

• Keep pages "light". Limit the number of images on a page to avoid (1) overwhelming customer and (2) putting a drain on bandwidth. If using FrontPage, an estimate appears in the lower right-hand corner. It’s an estimate of the time to download a page. Note: this estimate does not consider any server latency.

• Use "white space" appropriately when coding. Use tabs and blank lines, and indent.

• Place ASP start (<%) and end (>%) brackets around ASP code.

• Use "option explicit"; this helps to avoid typos.

• Declare DIM variables at the top of the coding.

• Comment code appropriately.

• Use client-side JavaScript where appropriate to make better use of bandwidth. Example: to advise user of required fields that have not been entered. Using JavaScript avoids sending entered data out to server and returning to user to request the additional required information. Good sites for JavaScripts include:

• Java language can be in JavaScript or VBScript.

• Don’t put "trade secrets" in JavaScript because savvy users can download the script using ViewSource.

• Use an include file at the top of the page for navigation and another at the bottom.

• Avoid or use care when cascading style sheets because they appear differently on different browsers.

• Group blocks of ASP code and blocks of HTML separately rather than intermixing them to eliminate going back and forth to the Server. Every time there’s a context switch, it must go into the ASP interpreter and come back out which cause the page to run slower.

• When entering quote marks around the string of text a user may have entered, be aware that the user may have entered a blank. You must account for that blank by a set of double quotes. Therefore, you may need to include three quote marks at the end of a string, two are a hard-coded quote and the third ends the string.

• When using "Option explicit", DIM your variables at the top in order to find them easily in order to make a change.

SQL Server is a relational database management system that runs on Windows NT and Windows 2000. There’s a master database within every SQL Server server instance. It contains information about the server itself, about the other tables that are in the server, some maintenance type Stored Procedures. Master is always there.

• Do not use the master database as a global repository for global data management purposes.

• Use Stored Procedures (SPROCs) for both reads and writes. It has living constructs, counting, decision making (then – else’s). You put a great amount lot of business logic inside SPROCs. A SPROC is faster than if SQL code is embedded as strings within the ASP code. A SPROC is compiled immediately. The database can optimize things easier if it’s in a SPROC. It does syntax checking. This may catch coding typos that otherwise may not be caught.

• Establish a naming convention for Stored Procedures. Upper and lower case and the underscore (_) may be used. The tool is NOT case sensitive when mixed case is used in a query.

• Do not use SP_xxxx for the naming convention for Stored Procedures because the master database uses this convention. You might accidentally use the same name as one of the standard stored procedures. If so, it will operate on the local database name before it goes to the master database.

• Do not use "Select *" (= Select All) when asking for field names. It wastes SQL Server time, especially when the list of field names is long. Be explicit about which field(s) should be returned.

OLE DB (Object Linking and Embedding Database) is more lightweight and advanced than ODBC (Open Database Connectivity) . It’s a faster technology that’s been available about 1-1/2 years. More and more OLE DB providers are becoming available.

• With OLE DB, use ConnectionString instead of a DSN (system, file, or user). A ConnectionString is much more portable.

• Use a Command or Connection object to execute Stored Procedures.

• Explicitly close the Connection and Recordset objects when you are finished with them to free up that Connection for the Recordset. Then set the object to nothing. Be sure to close them in that order.

• Protect each object by "On Error Resume Next/On Error Goto 0".