The space between the @ character and the directive and the requirement that directives be placed on the first line of a script are syntactically the most important features of an ASP directive. The failure to include the space or to include directives on the first line of a script are the most common errors when using directives.

You may ask yourself how you can have more than one directive in a script if directives, with the exception of <%= expression %>, must be placed on the first line of a script. To include more than one directive, use the following syntax:

<%@ DIRECTIVE1=ValueDIRECTIVE2=Value %>

You must include at least one space between each directive. Also, you must not place spaces around the equal signs (=).

Sets the character set (or code page) to be used to interpret the script on the server. Different languages and locales use unique code pages. This directive provides similar functionality for the interpretation of scripts on the server as the CodePage property of the Session object provides for client-side interpretation of the HTML sent to the client. However, it is important to note that the CODEPAGE preprocessing directive dictates how the script itself is interpreted, whereas the CodePage property of the Session object dictates how the resulting HTML is processed.

uintCodePage

An unsigned integer value corresponding to a valid code page for the web server running the ASP script

You can have both the CODEPAGE directive and the CodePage property for the Session object in the same script. This results in the server-side script being interpreted using the unsigned integer set for the CODEPAGE directive and the client information being interpreted using the code page set of the CodePage property of the Session object.

Turns the storage of user-specific session information on (True) or off (False). This value is True by default.

None

You also can enable session-state storage using the registry, but this directive allows significantly more flexibility (and on a script-by-script basis). If you have used a registry setting to control session-state information, then using this directive overrides that setting.

Setting this directive to False prevents you from storing any information in session-scoped variables or objects. This forces you to rely on other methods of maintaining information about each user, if you need to. However, it does provide some benefits:

It does not rely on your clients' browsers using cookies.

It increases the speed with which your server scripting is processed by the web server.

Sets the default scripting engine the web server will use to process the script in your ASP. This is set to VBScript by default.

ScriptingEngine

A valid scripting engine recognized by Internet Information Server. The valid scripting engines include VBScript, JScript, PerlScript, Python, and REXX.

Setting the LANGUAGE directive does not prevent you from using other scripting engines on your script page. It only sets the default scripting engine for interpretation of script on the current page. The following example shows how you can set the default scripting engine for the page to JScript and still use VBScript for a specific procedure:

<%@ LANGUAGE="JScript"%>
<SCRIPT LANGUAGE="VBScript" RUNAT="Server">
Sub ShowReport( )
	' This script will be interpreted using the VBScript 
	' scripting engine. 
End Sub
</SCRIPT>

Furthermore, setting the LANGUAGE directive value has no effect on the scripting engine used on the client side. Even if you set the LANGUAGE of the server-side script to PerlScript, for example, you can still set the LANGUAGE attribute of the client-side <SCRIPT> tag to JScript, as in the following example:

<%@ LANGUAGE="PerlScript"%>

<%
' All server-side script is interpreted using the PerlScript
' scripting engine.
%>

HTML here...
<SCRIPT LANGUAGE="JScript">
function btnReport_onClick
    ' This script will be interpreted using the JScript 
    ' scripting engine.
End Sub
</SCRIPT>

Note that only the VBScript and JScript scripting engines are included with IIS. All other scripting engines must be obtained and installed separately.

Sets a valid locale identifier for a given script. This directive specifies various formats (such as dates and times) to use for data on the server side.

dwordLCID

A DWORD (32-bit unsigned) value that represents a valid locale ID.

Just as setting the CODEPAGE directive has no effect on the CodePage property of the Session object and what character set is used on the client side, setting the LCID directive has no effect on the LCID used on the client side. However, it is important to note that the LCID preprocessing directive dictates how the script itself is interpreted, whereas the LCID property of the Session object dictates how the resulting HTML is processed.

Instructs the web server to treat the entire script as a single transaction. If you set the script as requiring a transaction, the web server uses Microsoft Transaction Server to ensure that the entire script is processed as a single unit (or transaction) or not at all. Currently, only database manipulation is available in transactions.

strValue

The possible values for the strValue parameter are as follows:

Required

Instructs the web server that the current script requires a transaction

Requires_New

Instructs the web server that the current script requires a new transaction

Supported

Instructs the web server not to start a transaction

Not_Supported

Instructs the web server not to start a transaction

Note that the value for the TRANSACTION directive is not a string. For this reason, you must use an underscore for those values that contain a space (Requires_New and Not_Supported). As discussed in Chapter 6, only a single script can be encapsulated in a transaction. You must ensure that the TRANSACTION directive is the first line in a transactional script. Otherwise, it will result in an error. Finally, you cannot encapsulate the GLOBAL.ASA code in a transaction.

If an error occurs in a script encapsulated in a transaction, Microsoft Transaction Server will roll back any actions that support transactions. Currently, only database actions support transactions. For example, not all disk activity is supported by MTS-based transactions and must be rolled back manually.