Amazon.co.uk Review
The book is organised in three parts: an introduction to ASP, a language reference, and appendices. This second edition has been updated for IIS 5.0 and ASP 3.0--the latest flavours of Microsoft's flagship Web server and scripting engines. The ASP introduction is very brief but adequately explains the basic concepts behind ASP and server-side scripting.
The heart of the title is the language reference that covers the intrinsic ASP objects plus ActiveX Data Objects (ADO) 2.6, Collaboration Data Objects, file access, and more. Each section is tagged with staggered page markers that usually make it unnecessary to resort to the book's index to find a topic.
While there are no full-blown code examples, the small code fragments that are included for most objects are valuable in illustrating usage. The information is accurate and to the point throughout, and that's exactly what busy programmers really need in a desktop reference. --Stephen W. Plain, Amazon.com
Topics covered:
- ASP overview
- Application of ASP objects
- ASPError
- ObjectContext
- Request
- Response
- Server
- Session
- Global.ASA
- Installable components (ActiveX Data Objects 2.6)
- Ad Rotator
- Browser Capabilities
- CDO for NT
- Content Linking
- Content Rotator
- Counters
- File Access
- Logging Utility
- MyInfo
- Page Counter
- Permission Checker
- Tools
- Converting CGI/WinCGI applications
- ASP on other platforms
- Configuring IIS
Amazon.co.uk Review
Not intended as a catch-all guide, the book is nonetheless an invaluable work, taking time to spell out in succinct terms the various commands together with their associated switches and parameters.
Divided into five sections, covering subjects including a full breakdown of the object model and a list of all of the installable components (the ad rotator, content linker and more), there's something here for programmers of all abilities, including invaluable guidance on use of the global.asa, preprocessing directives and server-side includes. Topped off with a useful set of appendices which give help and advice on topics including how to CGI applications to ASP and where to get hold of cross-platform ASP-based tools this is a must have for anyone who's serious about getting the most from ASP and NT server. --This text refers to an out of print or unavailable edition of this title.
Review
Product Description
ASP in a Nutshell provides the high-quality reference documentation that web application developers really need to create effective Active Server Pages. It focuses on how features are used in a real application and highlights little-known or undocumented features.
This book also includes an overview of the interaction between the latest release of Internet Information Server (version 5) and ASP 3.0, with an introduction to the IIS object model and the objects it comprises. The examples shown in this section and throughout the book are illustrated in VBScript.
The main components of this book are:
- Active Server Pages Introduction. Brief overview of the ASP application paradigm with examples in VBScript. Also included is an introduction to Microsoft's Internet Information Server 5.0, the IIS object model, and the objects that it comprises.
- Object Reference. Each object is discussed in the following manner: descriptions, properties, collections, methods, events, accessory files/required DLLs, and remarks, including real-world uses, tips and tricks, and author's experience (where applicable). The objects--Application, Response, Request, Server, Session, ObjectContext, and ASPError, as well as ASP Directives, Global.ASA, and Server-Side Includes--all follow this paradigm.
- Component Reference. This section follows the same paradigm found in Object Reference. The discussion covers all of the additional components included with IIS, such as ActiveX Data Objects, the Ad Rotator, the Browser capabilities component, the File System Object, and more.
- Appendixes. Gives examples in one or two objects and components using Perl, REXX, and Python in ASP.
Like other books in the "In a Nutshell" series this book offers the facts, including critical background information, in a no-nonsense manner that users will refer to again and again. It is a detailed reference that enables even experienced web developers to advance their ASP applications to new levels.
About the Author
Excerpted from ASP in a Nutshell by A. Keyton Weissinger. Copyright © 2000. Reprinted by permission. All rights reserved.
As of version 2.0, an important feature of Active Server Pages is the ability to create a transactional script: one whose constituent code segments all succeed completely or fail as a group. For example, using such a script, one section of code could remove a record from an inventory table, and a second section could add a record to a sales log table. However, only if both sections of code succeed does the script itself succeed. If the removal of the inventory record or the addition of the sales record fails, the script itself fails. Both processes are rolled back: the deleted record, if it was removed, is added back into the database, and the sales record, if it was added, is removed from the sales log table. This ability to wrap several functions in a single transactional unit that succeeds or fails as a whole is an important improvement in the power of ASP applications. Previously, all transactions relied on database transaction support.
ASP application transactions are controlled by Windows 2000 COM+ Component Services or Windows NT's Microsoft Transaction Server (MTS). This piece of the BackOffice suite allows control over all database actions coded to use it. Support for transactional scripts is built into IIS and Personal Web Server and does not require any special setup. Without COM+ Component Services or, in ASP 2.0, MTS transactional support, your applications would have to track all database changes manually and roll back all database actions by hand, keeping track of multiuser and concurrency issues, etc. MTS or COM+ Component Services gives this support for very little extra coding--as long as the database your application is connected to is Microsoft SQL Server or it supports the XA protocol from the X/Open consortium. Note that this means that file actions are not yet supported--or at least, not automatically.
ASP's support of transactions is coded through the use of the ObjectContext object, which represents the actual ObjectContext object of COM+ Component Services itself. By calling methods of the ObjectContext object and coding its events, you can create a transactional script with only a few more lines of code.
To declare all the script on a given page to be transactional, simply add the following line of code as the first line in your script:
For more details on the TRANSACTION ASP directive, see Chapter 11, Preprocessing Directives, Server-Side Includes, and GLOBAL.ASA. Here it is important only that this line be the first in your script; including this line alerts the web server to use Component Services to ensure that the script succeeds or fails as a whole.
To commit the transaction or abort it, you simply call the SetComplete or SetAbort methods of the ObjectContext object, respectively. If you are dealing with a complex transaction containing segments of code that are not supported by Component Services (notably file actions), you can specially code for these actions in the ObjectContext events OnTransactionCommit and OnTransactionAbort. There are examples of all of these methods and event procedures in the reference section later in this chapter.
Comments/Troubleshooting
There are currently two very important limitations in constructing transactional scripts:
Only database actions are supported, and only SQL Server and databases that support the XA protocol are supported by COM+ Component Services or MTS.
A transaction cannot span more than one ASP page. For this reason, you must be very careful in creating your pages: they must include all the actions required by your transactions but not be so large as to slow the processing of the page by too large a percentage.
If you write your own server components that complete some or all of the database actions in your transaction, that component must be registered in an MTS package.[1] MTS transactional support is provided only if the component is registered. What's more, you should create your own library packages and not include your component in the IIS in-process package. Custom library packages can be used by multiple ASP applications and are run in the same process as the ASP DLL. Setting up library packages also gives your component the ability to be pooled for reuse by your applications. This pooling is managed by MTS as well. You also can add your components to a server package, but doing so is required only for role-based transactions or transactions running on remote computers.
Note that you should not give objects functioning in transactions session- or application-level scope, since transactional objects are deactivated at the end of their transaction. If you do give such an object session or application scope, calls after the end of the transaction will fail and raise an error.
Although transactions are supported only for database actions, you can add code to the OnTransactionCommit and OnTransactionAbort event procedures to provide your own nondatabase transactional support. For example, code in these event procedures could easily be used to write or remove files from the file system upon success or failure of a given transaction.
ObjectContext exposes six methods other than the ones you can access through ASP. However, these are accessible only through code within the server components being managed by COM+ Component Services or MTS, and therefore are not documented here.
Transactional scripts are a very important addition to ASP. If you had access to database transactions only through use of ActiveX Data Objects, it would still be a very important and useful function. However, by creating custom server components, you can create complex and powerful transactions.
Methods Reference
SetAbort
ObjectContext.SetAbort
Aborts the transaction as a whole. When it is called, the transaction ends unsuccessfully, regardless of code that has or has not already been processed in your script.
