Programming Languages
What Active Server Pages (ASP)?
ASP (Active Server Pages) is a specification for a dynamically created web page with an .ASP extension that utilizes ActiveX scripting -- usually VBScript or JScript code.
When a browser requests an ASP page, the web server generates a page with HTML code and sends it back to the browser. So ASP pages are similar to CGI scripts, but they enable Visual Basic programmers to work with familiar tools.
ASP is an open, compile-free application environment, in which you can combine HTML, scripts, and reusable ActiveX Server components to create dynamic and powerful webbased business solutions. Active Server Pages enables server-side scripting for IIS with native support for both JavaScript and VBScript.
With ASP files, you can activate your web site using any combination of HTML, scripting - such as JavaScript or VBScript - and components written in any language. This means your ASP file is simply a file that can contain any combination of HTML, scripting, and calls to components.
ASP technology is built directly into Microsoft web servers, and is thus supported on all Microsoft web servers: Windows NT Internet Information Server (IIS) 3, 4 & 5, Windows NT Workstation and Windows 95 Personal Web servers.
Why ASP -vs.- CGIs? Because ASP runs as a service of the web server and is optimized for multiple threads and multiple users. This means that it's fast and it's easy to implement. If you use ASP, you can separate the design of your web page from the nitty-gritty details of programming access to databases and applications. This frees up the programmer to do what he/she does best - code - and, conversely, frees the designer to worry about just the design rather than the database.
Tips
Use the Application Object
For information that rarely changes and needs application scope (e.g. look-up info, constants), consider putting these into the Application object. Such values will be cached and be available to all scripts within the application, as well as acting as a central point for maintenance at a later stage.
Close and Free up Record sets/Database Connections after use
A classic bottleneck this one on servers, and one which can rapidly eat resources if not handled correctly. Ensure that all record sets and database connections are closed correctly after use, and objects are set =NOTHING where relevant. Generally, this should occur on the same page as they are created/opened (keep code symmetry), which will make best use of the database connection pooling on the server (if using ODBC, make sure connection pooling is enabled in the ODBC driver manager - if the option is not present, it will be worth your while upgrading MDAC on the server).
Avoid Hard Coding DSNs
Place ODBC DSN or OLEDB connection strings in either include files or in the application object. This ensures they are only stored in one place, aiding maintenance at a later date.
Use Map Path
To aid portability in your scripts avoid using literal file paths in your code and use MapPath instead. There is a small performance penalty for this, as this method requires the web server to retrieve the current server path. Hence, it is recommended to call this once and place the result into a variable for referencing later where possible.
Are your ASP scripts too long?
If you are like me, you like having all your code on one page! But this can really slow down the processes put on your server. If your scripts are 300 lines or so long, try thinking about re-coding them with a simpler process in mind or break them up into smaller pages. Use only the script you need to.
Creating more efficient scripts can improve performance big time!
Include files too big?
Don't think that by splitting up long pages into include files will help your speed. It won't. Why?
ASP processes all includes file statements, reads the entire file into memory and then compiles it into the original page i.e. your page + the includes.
Coding
Are you keeping your code together? Keeping blocks of ASP server-side script together can improve performance. For example:
<% If myvar = 1then %>
The Frog Jumped over the lake
<% else %>
I did not see a frog
<% end if %>
<% If myvar = 1 then
response.write "The Frog Jumped over the lake"
else
response.write "I did not see a frog"
end if %>
The second (although a very simple example) would be faster
ASP buffer
Are you buffering output?
Using Response.Buffer = False, note that while buffering may improve throughput, it may reduce perceived performance.
Disabled Session state
If you don't use session cookies on your site, why not turn off the checking for them? Like below:
<%@EnableSessionState= False %>
Do you use Server.MapPath?
How often do you use Server.MapPath? If you use it a lot, why not try using the full qualified path?
When you request Server.MapPath, you are generating an additional request for the server to process.
Here's just a few points you could check on when connecting and running Databases on your website
Are you returning just the required data?
Why return all the records when you might only need one or two, limit your SQL query right down to the right record you are after (saves using filters on your records!)
Are you explicitly closing Recordset and Connection variables?
How often do you close your Connections and other objects? It's just good coding
Are you using DSN-less connections?
To be honest, you can't always use a DSN-less connection to a database, but by doing so you are saving on the server having to process the DSN information!
Always use Option Explicit and variable naming conventions.
This tip is one of the simplest, but also among the most important. If you have programmed in Visual Basic, you probably know about Option Explicit. Option Explicit forces you to declare all variables before using them. If you don't declare Option Explicit, you can create nasty bugs by simply misspelling a variable name.
In the world of ASP there are two types of Option Explicit statements: client-side and server-side.
It is important to use both types of Option Explicit in your ASP code.
There is only one explicit data type in VBScript: a variant. Since a variant can represent many different data types, you should keep track of what data type you put into the variant. Otherwise, it is all too easy to forget what type of data is really in the variable. Microsoft suggests you use a form of Hungarian notation for VBScript. For example, intQuantity represents a quantity that is an integer data type.
Encapsulate your main body in a Main subroutine.
Global variables can lead to problems that are difficult to debug. It is very easy, for instance, to accidentally access a global variable from a function when you think you are using a local variable. All variables that you declare in ASP outside of functions are of global scope to the ASP.
To avoid incidental global variables, you can create a Main subroutine as the entry point for the ASP
Use server-side includes to maximize code reuse and maintainability.
Server-side includes (SSI) allow you to reuse code by including the same code in multiple files. SSTs are similar to C/C++ #include files. The VBScript engine inserts the code into the ASP file before any other compiling or interpreting is done. For example, if you had an SSI called ClientValidationInc.asp, it would be included in an ASP with the following statement:
Use On Error Resume Next carefully.
On Error Resume Next is the only mechanism available to handle runtime errors. As you may know, the On Error Resume Next statement causes the VBScript interpreter to jump to the next line if there is a runtime error. This allows you to handle the error more gracefully.
However, if you place On Error Resume Next so that it has global scope or is in your Main subroutine, you can accidentally disable all runtime checking and introduce difficult-to-find bugs. This is because it affects all the code following the statement, including all function calls.
Use session variables to assist in page redirection.
You can use session variables for data that must persist across multiple ASP pages. For instance, you can have a user enter a user ID and password and then use session variables to maintain the information across other ASP pages. You can do similar things with hidden fields or cookies, but session variables stay primarily on the server side. This makes them more efficient because it reduces network traffic and client-side processing.
There are a couple of potential pitfalls related to using session variables. First, session variables get deleted automatically when a session times out. You can control this timeout with the Session.Timeout property. Second, you can use the Session.Abandon method at any time to manually delete session variables. This is necessary if you want to manually recover the memory allocated on the server for the session variables.
Session variables do use HTTP cookies for their implementation, so they do have some of the physical downsides of explicit cookie use: a tiny amount of net traffic, and a few users complaining about cookies. They also use some memory on the server. On the whole, though, session variables are a lot easier to use than cookies.
Client side or server side?
There are two places where you can include user input validation: the client side or the server side. It is important to clearly understand what goes where. I use these rules to put the validation in the right place:
Rule 1: Put as much validation as you can on the client side.
Rule 2: If the user input validation requires database access, then that validation should be done on the server side.
The justification for Rule 1 is that response time is much better for the user if the validation is done on the client side. Suppose you have an ASP page that requires the user to input a Social Security number and get back information about the person that is assigned that number. On the client side, you should validate that the user-entered number uses the format of ###-##-####. There is no need to submit the page if the validation fails. On the server side, validate that the Social Security number is in the database. If it is not, display an error through redirection or some other mechanism
Handling Expressions
When you export a form as an ASP file, expressions aren't exported. In some cases you can create a query (or edit the existing one, if your form is already based on a query), and move your expressions into calculated fields in the query that underlies the form. This will work for most mathematical and string expressions. Any expressions that reference user-defined functions or functions not directly supported by Microsoft Jet will fail.
If your expressions can't be moved into a query, you have to determine if the expressions can be recreated using VBScript in the exported ASP files. If not, remove the controls with expressions from the form before exporting the form; otherwise, the controls will be displayed with #expression as their values.
Sorting and Filtering Records in an ASP File
When you save tables, queries, or forms that contain OrderBy and Filter properties as ASP files, and then browse the exported files, the record set is not sorted and it outputs all records. The Filter and OrderBy properties are not used in the SELECT statements in ASP files that Microsoft Access generates.
If you are saving a table or query as an ASP file, create a new query using the query design grid. Define sorting and selection criteria in the query design grid instead of using the OrderBy and Filter properties of the table or query. Save the new query as an ASP file.
If you are saving a form as an ASP file, create a new query using the query design grid. Define sorting and selection criteria in the query design grid instead of using the OrderBy and Filter properties of the form. Base a form on the new query, and then save the form as an ASP file.
Displaying Data from Lookup Fields
The data that is displayed in table Lookup fields created with the Lookup Wizard is ignored when you save a table as an ASP file. The bound column for the Lookup field is displayed in the ASP file, not the lookup data that you see when you open the table in Datasheet view in Microsoft Access.
This happens because the SQL statement that Microsoft Access generates for a Lookup field references data that is stored in another table. The bound column of a Lookup field's RowSource property is what is actually stored in the table (this is typically an ID field used to look up the data in the other table), not necessarily what you see when the table is displayed in Datasheet view.
To disp lay the lookup data, create an Auto Lookup query that includes the original table, as well as the table from which the Lookup field obtains its data. Use the corresponding fields from the lookup table in the query instead of the Lookup fields from the original table. Then save the query as an ASP file.
Saving Parameter Queries as ASP Files
When you save a parameter query as an ASP file, Microsoft Access will automatically generate an HTML form that has a field for every parameter in the query. This HTML form also includes a Run Query button that calls an ASP file to run the query.
When you save a parameter query as an ASP file, Microsoft Access displays parameter dialog boxes. Because Microsoft Access will create an HTML form for the parameter, it doesn't matter what you enter; just click OK. This is different from saving Static HTML where you must enter appropriate criteria when the parameter dialogs pop up.
Before you save a parameter query as an ASP file, open the query in Design view and make sure all parameter data types are explicitly declared in the Query Parameters dialog box (Query menu, Parameters command). If they aren't, SQL statements in the ASP file may not be delimited correctly.
Saving Queries That Contain Wildcard Characters
If you save a query that contains wildcard characters as ASP file, and then open the file in your Web browser, the browser either returns no records or an error message is displayed stating that the expression can't be used with the LIKE predicate.
This occurs because ASP files use Active Data Objects (ADO) to communicate with ODBC drivers in order to query the back-end data. The SQL statements required by ADO have different character requirements than typical Microsoft Access SQL statements. ASP files use the percent sign (%) as a wildcard character in SQL statements, whereas Microsoft Access uses the asterisk
Send mails with CDONTS
IIS 4.0 and above has a very useful server object: CDONTS. Using this it is possible to send e-mails from your ASP code very easily. Here you have an example of how to do this.
The Object (CDONTS.NewMail) has several properties and methods that you must know:
.From |
E-mail address of the sender |
.To |
E-mail address of the recipient |
.CC |
CC recipient e-mail address |
.Subject |
Subject of the message |
.Importance |
Importance of the message: |
.BodyFormat |
Format of the message |
.Value(Name) |
New header |
.Body |
Body of the message |
.AttachFile |
Attaches a file (it is needed to indicate the real path, |
.Send |
Calling this method the message is sent |
|
|||