This white paper documents the implementation of the first phase of Microsoft Direct, a Web site that provides online order management and customer assistance services to shoppers acquiring Microsoft® products.
Microsoft offers a wide range of products, including software, hardware, courseware, and publications, that are suited to high-volume retail distribution over the Web. There are many independent online resellers who have Web storefronts that offer Microsoft products, along with other information technology products from other Vendors. Microsoft Direct’s mission is to serve those shoppers who wish to acquire their Microsoft products directly from Microsoft.
Microsoft Direct achieves this through the concept of Tenants. A Microsoft Direct Tenant is an online storefront, linked to Microsoft Direct, that hands shoppers over to Microsoft Direct as soon as they have selected all the Microsoft products they want to order. A shopper wishing to buy directly from Microsoft selects Microsoft Direct from a list of online resellers displayed by the Tenant. Microsoft Direct processes the order, calling on a variety of online Vendors for services such as credit card payment and shipment, and provides extensive Web-based customer assistance services.
These Web-based customer assistance services are the core business justification for the implementation of the Microsoft Direct site. Before Microsoft Direct went live, all customer assistance services were handled over the phone by Microsoft customer service representatives. These services included locating orders and shipments, handling order changes, and processing product returns, and cost approximately $5.00 per transaction because of the high administrative efforts involved. While customer assistance is still available over the phone, Microsoft Direct enables most shoppers to help themselves using their Web browser. The savings are considerable—Microsoft Direct processes about 60,000 order transactions per day—and makes a major contribution to the profit margins of both Microsoft Direct and its Tenants, who would otherwise have to offer such services themselves.
Microsoft Direct’s charter is to support multiple Tenants and Vendors in one system infrastructure. Its first Tenant was Microsoft’s own online retail store, shop.microsoft.com, which refers Web-initiated orders for hardware, software, and publications that are shipped to consumers in the USA or Canada, paid for by credit card. Microsoft Direct is designed to accommodate future implementations of other Tenant types, payment methods, geographic locations, and fulfillment Vendors.
Having one scalable infrastructure capable of serving multiple Tenants is a key objective of Microsoft Direct. A multi-Tenant capability reduces the joining cost and time-to-market for new Tenants, for example, organizations selling courseware or software licenses to small and medium-sized businesses. It also allows easy integration with other major electronic commerce initiatives at Microsoft, such as Online ID that provides user authorization services across the company.
Microsoft Direct’s own electronic commerce technology includes Microsoft Site Server 3.0 Commerce Edition, Microsoft Windows NT®, and Microsoft SQL Server™ 6.5. The current configuration, which is designed to process up to 60,000 shopper transactions per day with a single database server, can easily be scaled by adding additional database or Web servers as required. The Tenant and Vendor interfaces have to meet the needs of a growing variety of storefront and fulfillment systems, and have been built to make it easy for new Tenant and Vendor channels to come aboard.
Key ingredients in Microsoft Direct’s success have been managing the integration with other projects that were also in development, and the performance evaluation work that helped optimize response times and ensured future scalability. After more than a year of planning and development, Microsoft Direct went live for U.S. shoppers in February, 1999, simultaneously with its first Tenant, shop.microsoft.com.
There are four main components to the Microsoft Direct solution: Tenant, Order Management, Customer Service, and Reports. The Order Management and Customer Service components are the subject of this white paper.
Microsoft Direct’s Order Management application is an online process that accepts Web-initiated orders for physical goods, calculates prices, taxes and shipping charges, and accepts credit card payment for the order.
Web orders arrive online via a Tenant, an online store that has already allowed the shopper to select products, and has verified shopper name and address and shipping information before passing the shopper to Microsoft Direct. An example of a Tenant is shop.microsoft.com, which invites the shopper to select products from a catalog, and choose a reseller from a list (which includes Microsoft Direct) to have their order fulfilled.
The order basket, shipping, and payment information are displayed for the shopper in a single page on entering Microsoft Direct (see Figure 1 below).
A deliberate design choice was made to display the information all in one page, based on shopper behavior and performance considerations. The alternative, to display basket, shipping, and payment information on separate pages, would have caused a large number of unnecessary pages to be sent, because so few shoppers elected to change the shipping and payment information that they had previously provided to the Tenant.
Figure 1: The Microsoft Direct Order Handoff Page
The Microsoft Direct process accepts the shopper from the Tenant, checks inventory, extends the order pricing, calculates shipping charges and sales taxes, and validates the credit card number. The shopper has the opportunity to modify the shipping and billing details that they supplied to the Tenant, and the committed order is then passed to a service Vendor for physical delivery.
The design of the Order Management application allows for a considerable scaling of order volumes, and the future implementation of other Tenant and Vendor types and payment methods. The major features of the Order Management component are:
The Customer Service component includes two applications:
The business justification for Microsoft Direct depends on the great majority of shoppers being able to resolve their own queries using the Internet Customer Service application.
A shopper unable to resolve a query, for example, because of a forgotten password or order number, may contact a customer service representative by phone. A voice response system offers opportunities to resolve queries before speaking with a live representative. The Customer Service Representative application includes the functionality of Internet Customer Service, plus the ability to search across the database for specific orders or shoppers.
Figure 2 shows an example of the initial Internet Customer Service page. The shopper may choose to view an order, request customer assistance, or find answers to frequently asked questions.
This page displays all orders that have been placed by the shopper for the past year with a colored icon flag indicating the status of the order. The shopper can click on either the order number or the order status icon for detailed information about the order.
Figure 2: Initial Internet Customer Service Page
Figure 3 shows an example of the detailed information available to the shopper on an individual order. This page shows the status associated with individual items as well as the shipping address, method of payment, and order totals.
Figure 3: Order Status Page
Figure 4 shows an example of the detailed information available to the shopper on an individual item. This page shows the associated shipping information, such as shipping date, carrier, and tracking number, if available.
Figure 4: Item Status Page
Clicking on the shipper logo or the tracking number spawns a new window linked to the shipper’s information page for the specified tracking number.
Figure 5 shows an example of the various types of customer assistance available on an order. These range from technical support, to issues, to problems with the order. The shopper chooses the reason for assistance from a drop-down menu, which is then linked to different pages to obtain the appropriate information for the request.
Figure 5: Initial Internet Customer Service Page
Figure 6 shows an example of the Frequently Asked Questions (FAQ) page. Questions are organized in categories and are in a question/answer format.
Figure 6: Frequently Asked Questions Page
Figure 7 shows an example of the initial Customer Service Rep (CSR) page. The CSR sees the identical customer service pages as the shopper sees on the Web site, but in a frame format with additional functionality such as search functions.
Figure 7: Initial Customer Service Rep Page
Scalability Requirements define how well the system is able to expand to handle increases in the volumes of transactions. For Order Management, this means the design must still perform well as multiple IIS/ASP servers are added in the future to meet the increased load.
The production and development servers are both capable of storing 5+ gigabytes of information. The configuration has the capacity to add storage if and when needs increase.
Performance Requirements define how well the system is supposed to work. The Order Management pages are characterized by a mix of (1) pages that require database access or data entry and (2) static dead-end error message pages. Performance requirements include:
Reliability Requirements define how well the system is able to respond to outside events in a consistent and appropriate manner. The system undergoes Usability Testing as the first step of the release process.
The system undergoes Integration Testing before undergoing User Acceptance Testing (UAT) and System Acceptance Testing (SAT) in parallel as the final step before release. The system is Microsoft Y2K compliant.
Full site backup (capacity and replication functions) exist on separate drives to ensure instant replacement in the event of catastrophic failure.
A fault tolerant system provides server redundancy in case of failure. Appropriate backup and recovery procedures are to be followed to enable switching to an alternative system in the event of a catastrophic failure.
Maintainability Requirements define how the system is to be maintained at an operational level once it is put into production. Code maintenance must be considered from the start to avoid unnecessary confusion in future system maintenance.
The system adds new types of Tenants, Vendors, and products through a system admin interface.
Use objects and put common functions into include files. All processing is performed in objects that are separate from the ASP page. In other words, they are stored in separate JavaScript routines that are callable from the main body of the ASP page.
All variable names use the defined naming conventions. All code includes comments identifying the functionality of major sections and complex processing.
Availability Requirements define the accessibility of the system. Microsoft Direct is available to the general public from the Internet 24-hours a day, with occasional shutdowns at pre-determined times and dates being acceptable for regular system maintenance during off-hours (weekends and early morning). Brief page unavailability is acceptable during content updates.
Usability Requirements define the ability of the system to make people comfortable that they are effective when using the system. The system adheres to basic Internet Web conventions. JavaScript is used to validate form input on the clients computers before submission to the server, for example to ensure that numeric values only contain numbers and eliminate any quotation marks.
Microsoft Direct was designed for Microsoft Internet Explorer 4.0 technology, but with the ability to degrade gracefully to other browsers. The graphic interface is optimized for 800x600 resolution, with gracious scaling to larger sizes (e.g. 1024x768) and workable at 640x480.
Microsoft Direct supports the following client platforms:
Microsoft Direct server hardware and software requirements are defined in the section "Physical Architecture."
The figure below summarizes the overall application architecture of Microsoft Direct. The components shown in the figure are discussed in more detail in subsequent sections.
Figure 8: Microsoft Direct Application Architecture
The Tenant Shoppers are individuals who are shopping online at one of the Tenant Store sites, such as shop.microsoft.com. They interact with the Tenant Store and then the Microsoft Direct order management system. This is also the source for customer service interactions.
This is the online store the shopper interacts with. Microsoft Direct is not directly involved in the development of this component. However, a shopper is brought to the Microsoft Direct system by way of a Tenant Store, so both the Tenant Stores and Microsoft Direct need to understand the interface and how it is implemented.
Online ID is the secure authentication system that is used to validate all external users of secure in-house systems. It also manages persistent session routing to the several Microsoft Direct front-end processors.
This represents the order handoff, order management, customer service, and customer rep support pages.
This represents the pipelines the Microsoft Direct system uses to support the order management process.
This is the database service functionality that provides all database interaction. All interfacing with the database is done via stored procedures.
This represents the services that handle the depicted data feeds, import/export processing, order status updating, inventory updates, and so forth.
This represents the master transaction database that holds all shopper-committed orders that are in process. Completed orders are kept here as well in history tables.
This section describes the process flows used in the implementation of Microsoft Direct’s Order Management and Customer Service components.
Figure 9: Microsoft Direct Process Order Management Flows
The Order Handoff Page provides an application interface for the Tenant to post their shopping basket to the Microsoft Direct System.
Figure 10: Microsoft Direct Customer Service Flows
Tenant interface processes are needed to maintain an up-to-date SKU list for the Tenant, to receive the incoming shopper and their basket, and to report back to the Tenant on the final status of the transaction. Tenants may choose the type of interface they prefer. For example, Microsoft Direct’s first Tenant, shop.microsoft.com, chose to refer shoppers to Microsoft Direct using the graphic user interface and a flat file containing basket information. Tenant interface processes include:
Internal batch processes are used both in order management, to enforce business logic on a committed order, and for internal housekeeping, for example to periodically remove abandoned shopping baskets. Internal batch processes include:
External interfaces create files of new orders, update Vendor inventory and order status, and refer financial data back for end-user reporting. They include:
Figure 11 below shows the main interface and batch processes required for Microsoft Direct.
Figure 11: Microsoft Direct–Interface and Batch Processes
Product management is a process where products are added and updated in the Microsoft Direct environment. Microsoft Direct only maintains those product SKUs that are supported by their Tenants.
The Tenant provides a list of SKUs to Microsoft Direct. Microsoft Direct updates the product_sku table based on the Tenant’s SKUs. The SKU is associated to the Vendor/Tenant during the inventory status feed. Microsoft Direct utilizes all Tenant fields except availability.
Figure 12: Tenant Interface Process–Product Management
The Tenant can submit an order by user interface or by a batch submission. Each order on the batch process must go through the Accept Order process. The Tenant is assumed to have validated shopper name and address details.
Table of Denial: Microsoft does not conduct business with individuals or companies appearing on the U.S. Government’s Lists of Denied Parties. This is enforced, via standard Embargo Lists and Table of Denied Parties (TDO) processes, on orders to be shipped outside the United States.
Cleanup: For Internet users with HTML clients, it is quite likely that many of these customers, after having selected several items for purchase, will move to another Web location or simply turn off their computer. This situation requires that a scheduled ’clean-up’ process be executed to remove all inactive shopping baskets (order forms or objects) that are uncommitted. Uncommitted orders are those orders that have not been committed by the Customer through the ‘Purchase My Order’ button on the Price Order page.
This process is executed every hour, looking for shopping baskets that have been inactive for 1.5 hours.
Figure 13: Internal Batch Process–Cleanup
All orders that have been successfully purchased by the Customer are sent to the Vendor (orders with the status of ‘Order Accepted’). This interface is run approximately four times a day.
There are six distinct external batch interfaces required to support communication between the Microsoft Direct order management system and its multiple Tenants and fulfillment Vendors. The figure below provides an overview.
Figure 14: Microsoft Direct Batch Interfaces
Microsoft Direct is designed to make extensive use of tables, both for business data and for system parameters. The business data architecture is organized into three groups of tables, Order Management, Customer Service, and Feeds. The architecture for each group of tables is shown in the following figures. The stored procedures implemented for each major table are shown at the end of this section.
Figure 15: Order Management Tables
Key to Order Management tables
| 1. Basket | 11. Next Number | 21. Ship Rate Ord Qty |
| 2. Basket Item | 12. Payment Method | 22. Ship Rate Ord Value |
| 3. Bogus Credit Cards | 13. Product Inventory | 23. Shopper |
| 4. Country | 14. Product Price | 24. Tenant |
| 5. Credit Card | 15. Product SKU | 25. Tenant Ship Method |
| 6. Currency | 16. Receipt | 26. Unacceptable Word |
| 7. Denial Country | 17. Receipt Item | 27. Unit |
| 8. Denial Master | 18. Receipt Transaction | 28. Vendor |
| 9. Forbidden Country Code | 19. Ship Method | 29. Vendor Credit Card |
| 10 Freight Code | 20. Ship Rate Flat | 30. Vendor Field |
Figure 16: Customer Service Tables
Key to Customer Service tables
| 1. Browser | 11. Order Status |
| 2. CS Issue | 12. Order Status Reason |
| 3. CS Issue Comment | 13. Receipt |
| 4. CS Reason | 14. Receipt Item |
| 5. FAQ | 15. Return Reason |
| 6. FAQ Answer | 16. Return Request |
| 7. FAQ Question | 17. Shipper |
| 8. Item Status | 18. Tenant |
| 9. Item Status Reason | 19. Tenant Assistance |
| 10. Operating System |
Figure 17: Feed Tables
Key to Feed tables
| 1. Feed Completion Status | 7. Inventory Feed Stage |
| 2. Feed Control | 8. New Order Feed Stage |
| 3. Feed Log | 9. Order Status Feed Stage |
| 4. Feed Schedule | 10. Product Feed Stage |
| 5. Feed Type | 11. Referral Status Feed Stage |
| 6. Incident Feed Stage |
The Microsoft® SQL Server stored procedures used to select, update, or delete data items in the tables are listed below:
Table 1: Database Tables Used
| Table | Stored Procedure | Action Performed |
| Basket | Delete Shopper | Delete |
| Insert Basket | Insert | |
| Update Basket | Update | |
| Basket Item Delete | Delete | |
| Basket Tenant Sel | Select | |
| Basket Ship Cutoff | Select | |
| Basket Ship Update | Update | |
| Receipt Master | Select | |
| Basket Info | Select | |
| Basket Item | Delete Shopper | Delete |
| Insert Basket Item | Insert | |
| Basket Item Delete | Delete | |
| Basket Item Qty Update | Update | |
| Basket Item Remove Item | Delete | |
| Basket Item Shopper Id | Select & Delete | |
| Basket Item Shop Id Item Id | Delete | |
| Receipt Master | Select | |
| Basket Item | Delete | |
| Bogus Credit Cards | Bogus Credit Cards | Select |
| Denial Country | Order Denial | Select |
| Denial Master | Order Denial | Select |
| FAQ Answer | FAQ Select OM | Select |
| FAQ Questions | FAQ Select OM | Select |
| Next Number | Receipt Master | Select & Update |
| Product Inventory | Inventory Check | Select |
| Basket Item Qty Update | Select | |
| Prod Inv Quantity | Update | |
| Receipt Master | Update | |
| Receipt | Receipt Tenant Sel | Select |
| Receipt Master | Insert | |
| Receipt Shopper Online ID | Select | |
| Receipt Shopper Order ID 2 | Select | |
| Receipt Item | Receipt Item Get Item | Select |
| Receipt Master | Insert | |
| Receipt Transaction | Receipt Master | Insert |
| Ship Method | Inventory Check | Select |
| Tenant Ship Method | Select | |
| Ship Rate Flat | Calculate Shipping | Select |
| Ship Rate Ord Qty | Calculate Shipping | Select |
| Ship Rate Ord Value | Calculate Shipping | Select |
| Shopper | Delete Shopper | Delete |
| Insert Shopper | Insert | |
| Basket Info | Select | |
| System Control | CSR Main Lobby | Select |
| System Control Item Value | Select | |
| Tenant | Get Tenant Code | Select |
| Tenant Mer Change Page URL | Select | |
| Tenant Shopping Page URL | Select | |
| Tenant Ship Method | Select | |
| Tenant Ship Method | Tenant Ship Method | Select |
| Unacceptable Word | Order Denial | Select |
| Vendor | Inventory Check | Select |
| Basket Item Qty Update | Select | |
| Basket Ship Cutoff | Select | |
| Get Vendor Code | Select | |
| Vendor Credit Card | Vendor Credit Card Get CC | Select |
| Vendor Field | Vendor Fields | Select |
The Microsoft Direct physical architecture is shown below in Figure 18. It consists of four Web servers, three DB servers (Production, Reporting, and Hot Backup), and a server for Tenant Services and E-mail.
Load balancing services are currently provided through a “BIG/ip” controller that distributes transactions across the IIS server array. The BIG/ip implementation was separate from the Microsoft Direct project. Future plans are to replace BIG/ip with Microsoft’s own load balancing solution called Microsoft Windows NT Load Balancing Service (WLBS).
For more information on Microsoft’s WLBS (load balancing technology), refer to http://www.microsoft.com/NTServer/ntserverenterprise/exec/feature/WLBS/default.asp.
Figure 18: Microsoft Direct Physical Architecture
Table 2: Server Configurations
| Server | # | Configuration | Hardware | Speed |
| IIS | 4 | Microsoft Windows NT 4 SP4, Internet Information Server 4, CS, Taxware | Dual Xeon 400 with 1GB RAM, 1MB L2 Cache | 400MHz |
| SQL Production | 1 | Microsoft Windows NT 4 SP4, Microsoft SQL Server 6.5 | Quad Xeon 400 with 1GB RAM, 1MB L2 Cache | 400MHz |
| Service/Email | 1 | Microsoft Windows NT 4 SP4 | Dual Pentium II with 196MB RAM, 1MB L2 Cache | 400MHz |
| SQL Reporting | 1 | Microsoft Windows NT 4 SP4, Microsoft SQL Server 6.5 | Quad Xeon 400 with 1GB RAM, 1MB L2 Cache | 400MHz |
| SQL Hot Backup | 1 | Microsoft Windows NT 4 SP4, Microsoft SQL Server 6.5 | Quad Xeon 400 with 1GB RAM, 1MB L2 Cache | 400MHz |
Microsoft Direct has two main security requirements—ensuring that the appropriate customer is validated, and limiting access to secured data to appropriate individuals only.
Orders are only viewable by the Authenticated Customer (and the Customer Service Rep, if customer service is later required).
All users must be authenticated through an “Online ID” authentication process, and all ASP pages and databases are maintained in the Online ID secured environment. Online ID is a company-internal authentification service, built using Microsoft technologies, that provides a single way for users to identify themselves to Microsoft’s numerous in-house systems.
All confidential information, such as a customer personal information and credit card numbers, are only stored in the transaction; they are not centrally available. Enhanced security of credit card numbers is provided by encrypting the information prior to storing it in the transaction database.
The credit card number field is cleared on re-entry to the Price Order page.
The system supervisor receives reports of successful system administration log-on/off events, as well as unsuccessful attempts.
The administrator group has limited membership. Only a select few employees have administrator privileges to the production servers. A select bigger group has access to the development server necessary to update content. Only Web administrators will have the ability to post new content to production servers.
Auditing of NTFS files and directories is enabled, to ensure that no one has gained unauthorized access to sensitive files.
Secure Sockets Layer (HTTPS) is used to enforce secure data transmissions. This is required for the transfer of shopper profile and shopping basket data between the Tenants and Microsoft Direct.
All the latest Windows NT service packs and security patches were in place before the new system went live. They are maintained as required by the Webmaster.
The Microsoft Direct development team implemented the functional specification using Microsoft Site Server 3.0 Commerce Edition with IIS4 and Microsoft SQL Server 6.5, on a Windows NT 4.0 Server to provide the primary functionality of Order Management.
Database access is accomplished using the Active Data Object (ADO). The application is designed to work best with Microsoft Internet Explorer 4.x at a screen resolution of 800x600, but degrades gracefully in all 3.x browsers.
The Customer Service application uses servers running Windows NT 4.0 and IIS4 with Active Server Pages (ASP). Database access is accomplished using the Active Data Object (ADO). The application is designed to work best with Microsoft Internet Explorer 4.x at a screen resolution of 800x600, but degrades gracefully in all 3.x browsers.
The HTML and artwork guidelines were initially provided by a graphics design firm, but the majority of the graphics were created and optimized by the development team.
This section describes the timeline, resources, and main code components needed to meet the application architecture and system requirements of the Microsoft Direct implementation.
The Microsoft Direct online site was built using a combination of Microsoft full-time employees and contractors. The following is a breakdown of some major tasks that were performed and how resources were distributed to accomplish them.
Table 3: Development Task
| Task | People Resources | Time-frame | % of total effort |
| Business Analysis | 3 | 7 | 30% |
| Technical Analysis | 2 | 7 | 20% |
| HTML/ASP Development | 2 | 5 | 15% |
| Data Modeling & SQL DB Development | 1 | 5 | 7% |
| C++ Development | 2 | 5 | 15% |
| Testing | 3 | 3 | 13% |
Microsoft Direct implementation began by modifying VCTurbo, an improved version of the Volcano Coffee sample store distributed with Site Server 3.0 Commerce Edition. This Commerce sample stores used two pipelines:
The VCTurbo sample store splits the plan pipeline into two, Basket.pcf and Total.pcf. Because Microsoft Direct displays basket, shipping, and total information all in one page, the two pipelines were merged into one, Plan.pcf, and executed at the beginning of the page. Basket.pcf is executed to get billing and shipping information.
We did not use Purchase.pcf due to performance considerations with our single-page approach, and due to the way credit checking is currently performed in Microsoft Direct. Since it is a performance hit running the pipeline each time the shopper refreshes the page, the Plan.pcf pipeline is executed in the order_handoff page, where the data is first posted from the Tenant and written into the database. From then on, all the required data such as order total and shipping rate was already in the database, we were able to remove two of Purchase.pcf’s three components, SQLItemADO and SQLOrderADO, and replace them with a stored procedure. We removed the third component, ValidateCC Number, since credit checking is currently defined as a Vendor responsibility.
We found that the SimpleUSTax component was not sufficient to calculate sales tax, mainly because it defines tax rates at state level, and there was no way to take into account any small variations in rates between counties within a state. Therefore, we used Taxware’s Internet Tax System component to calculate tax. While this was the same component used by our Vendor to calculate tax totals, we initially found some small differences between the totals we calculated for the order_handoff page and those calculated by the Vendor when the credit card was charged. The differences were rounding errors, and were overcome by calculating taxes in our .asp page at line item level and totaling the tax, rather than totaling the order and then calculating the tax total:
For each item in mscsOrderForm.items Item.[_tax_total] = int(item.[_tax_total]/item.quantity)
Tax_total = tax_total + item.[_tax_total]
Next
In the Billing and Shipping pages, the address is validated using the tax component by means of an ISAPI extension DLL written by a member of the development team, using Microsoft Visual C++®, Microsoft SQL Server 6.5, and ODBC 3.x.
The technical design called for using Site Server 3.0 Commerce Edition in a way that ensured the technology delivered maximum performance benefits. The design is based on several recommendations included in the Microsoft Site Server 3.0 Commerce Edition Performance Kit. The Performance Kit contains detailed technical advice on how to design a Site Server Commerce site while keeping performance a priority.
The Site Foundation Wizard was run to set up the Microsoft Direct foundation and the Site Builder Wizard was used to build the Microsoft Direct Commerce Server site. The VCTurbo site (included in the Performance Kit) was used as a model. This wizard gathered information from the VCTurbo site and generated the files and database for Microsoft Direct using VCTurbo specifications. The database and template files provided by the wizard were then customized to add site-specific functions, and create ASP pages that conform to Microsoft Direct requirements.
Outlined below are the design principles used to get the maximum performance benefit from Site Server 3.0 Commerce Edition. Please refer to the Performance Kit for more details.
Microsoft Direct focused on a design that could be extended to support additional capabilities and store Tenants. Microsoft Direct’s first Tenant, shop.microsoft.com, also turned out to be a Commerce Server 3.0 site. It was therefore possible for Microsoft Direct to look at adapting some of the Tenant’s components, to minimize development effort and complexity. This possibility was investigated during detailed design, and any benefits were weighed against possible lost functionality and other tradeoffs.
The following seven stages, which are included in Commerce Server’s default Plan Pipeline, were removed from Microsoft Direct pipeline processing. The functionality of some components was removed altogether, while the logic of others was duplicated elsewhere in the site.
Table 4: Plan Pipeline Stages
| Stage | Reason for removal from pipeline processing |
| Product Information | Gathered by executing a query directly in script on an ASP page. |
| Merchant Information | Removed, functionality not required for Microsoft Direct. |
| Shopper Information | Gathered by executing a query directly in script on an ASP page. |
| Order Initialization | Removed, allocate Order ID using order_id identity database column. |
| Order Check | Removed, functionality not required for Microsoft Direct. |
| Item Price | Removed, functionality not required for Microsoft Direct. |
| Item Price Adjust | Removed, functionality not required for Microsoft Direct. |
Taxware is a third-party component that Microsoft Direct is using to compute tax for the different localities in the United States and Canada. In addition, it is used for address verification if either the billing or shipping address is entered after arriving at the Checkout page. It is the Tenant’s responsibility to verify addresses they provide to Microsoft Direct.
We learned how to control the caching of user pages, by overriding automatic page caching on the proxy server and by modifying our .asp pages.
By default, Web pages get cached for performance reasons, both by the proxy server and by the Web browser on the shopper’s computer. Problems with this default caching of user pages can arise when a page is revisited soon after information has been edited or added, because the caching mechanism may later restore the original, unedited version of the page. This can affect the shopper in several ways, depending on where they are in their navigation, and on the browser version they are using:
Proxy servers cache Web pages to increase the speed, but this is only good for display/read only pages. We therefore changed their Response.CacheControl configuration parameters from public to:
Response.CacheControl = “private”
We also changed the value of the ExpiresAbsolute property, so as to specify an already-past date and time at which a browser-cached page expires, by including the following line of code in every .asp page:
Response.ExpiresAbsolute=#Jan 01, 1980 00:00:00#
Finally, we removed a Meta tag from our .asp pages that was causing problems for some browser versions:
<META HTTP-EQUIV=”PRAGMA” CONTENT=”NO-CACHE”>
The Microsoft Direct E-mail Service is used to notify shoppers about the status of their orders. We had to develop an e-mail solution that used the minimum number of Windows NT threads, was data-driven for business reasons, and restarted quickly and automatically after an interruption in server availability. Further, the E-mail Service needed to be automated, and must be capable of working successfully with the wide range of e-mail clients that our shoppers used. Keeping these business requirements in mind, the E-mail Service was developed using Collaboration Data Objects for Windows NT Server (CDONTS) for messaging, Microsoft SQL Server 6.5 for maintaining the delivery of e-mail messages, and custom developed-COM objects created in Microsoft Visual C++ for integration.
Our initial E-mail Service solution used a different Windows NT thread for each distinct e-mail type. Although this solution worked well, we had to modify it because it took an unacceptably long time to exit so many threads whenever the Service was stopped. By grouping most of the less-critical e-mail processing into one thread, we were able to settle on just two threads as the best solution. One thread acts on the most vital transaction, the Order Confirmation E-mail for the new orders received, and the second thread deals with all other types.
Our biggest challenge came as a requirement from our business side that e-mail formats and content, such as the From E-mail address, should be data driven so that they can be set at run time. The NewMail interface of CDONTS.dll proved lightweight and flexible enough to meet this requirement. All parameters to configure and run the E-mail Service are now held in the registry. This gives us the ability to configure the E-mail System to the needs of individual Tenants, and to modify the application by adding or removing any type of e-mail. A new e-mail type can be added by writing a new Stored Procedure and adding the name to the registry.
We introduced exception processing so that that the E-mail Service won't crash even if Microsoft SQL Server goes offline. We made this possible by continuously polling the server until it becomes available again. We also made sure that when we dealt with such a vast amount of data, we were not repeatedly allocating and de-allocating heap memory within the E-mail Service. Based on a flag in our ODBC wrapper class, we allocated memory only once and used it for the entire session.
Microsoft Direct system requirements included the support of a wide range of browsers and Internet technologies, running on many different operating systems (Macintosh OS 8.1+, Microsoft Windows 3.1, Microsoft Windows 95/98, and Microsoft Windows NT 3.51+). A number of development issues needed workarounds because the implementations of HTML and scripting engines vary between these browser versions. The table below itemizes these issues and the workarounds that were required.
Table 5: Browser support workarounds
| Browser-dependent issues | Workarounds |
| Browser does not support JavaScript arrays. Inputs cannot be passed to a subsequent page that processes the values by looping through an array. | All inputs must be explicitly named on the page and passed as such.
Client-side validation cannot use arrays to check input fields. Note Internet Explorer 3 and Netscape Navigator 2 both support JavaScript 1.0 (called JScript® 1.0 in Internet Explorer 3), which doesn't support the IMAGE object available in JavaScript 1.1. |
| Browser does not support the substr(start, end) JavaScript function. | Use the JavaScript substring(start,length) function. |
| Browser requires functions to always return values if any statement returns a value. | Ensure that statements end with return; return true; or return false; throughout. |
| Browser does not support js files. | Code must sniff for browser, then return either js file or script on page. |
| Browser does not always handle query strings passed with posts. | ACTION value should not have query string appended. |
| Browser requires function to open new window. | <A HREF='javascript:loadWindow("<%= Application("OrderRootStr")%>terms2.asp")'> |
| Browser does not show tool tips. | Use the ALT and NAME attributes for images. |
| Browser may ignore hash at end of query string. | Explicitly define hash in onload script. |
| Browser may cache page or inputs when not desirable. | set INPUT TYPE=hidden flag onunload
set Expires META tag set META pragma tag |
| Browser implements auto-complete, which is undesirable for sensitive credit-card information or personal data. | Set AUTOCOMPLETE = “off” on INPUT |
| Browser persists form input data. | Set META tags SAVE=history and SAVE=favorites, but do not apply these attributes to any objects on the page. |
| Browser reserves space for FORM when rendering page, even if no renderable markup within form. | Locate form information where the impact on rendering minimized. |
| Some browsers display only the image NAME tag text when the cursor is over a button or form object, rather than the informative alternate ALT text. | |
| Nested tables significantly increases download and rendering times for some browsers. | Keep the number of nested tables to a minimum. |
The major technologies used in the development of Microsoft Direct included:
Additional development tools are listed below, with an explanation of how they were used.
Table 6: Microsoft Direct Development Tools
| Development area | Tool | Explanation |
| Administrative | Microsoft Visual SourceSafe™ 6.0 | Used for source control and maintaining build revisions. |
| Microsoft RAID | Bug and issue tracking system. | |
| Remote Desktop | Used to administer remote servers. | |
| Microsoft SQL Server Enterprise Manager | Used to administer the Transaction DB. | |
| Microsoft Commercial Internet Server Admin | Used to install and configure Commerce Server. | |
| Microsoft Internet Information Server Admin | Used to install and configure IIS 4.0. | |
| Microsoft Office 98 | Test Plans and reports. | |
| Prototyping | Microsoft FrontPage® 98 | Quick design look and table creation. |
| Authoring | Microsoft Visual Studio 5/6 (Microsoft Visual C++, Microsoft Visual InterDev™) | Core development tool. |
| Microsoft Visual InterDev | Test Web site development and maintenance. | |
| Commerce Server Pipeline Editor | Used to install Taxware components. | |
| Microsoft SQL Enterprise Manager | Used to develop stored procedures. | |
| Testing | HTML Validator | Check validity of HTML code. |
| Web Trends | Web site performance monitoring and reporting. | |
| Microsoft Access 98 | Database querying and manipulation. | |
| Graphics | Adobe ImageReady 1.0 | Used for optimizing Web graphics, automating batch conversions, and animations. |
| Adobe Photoshop 5.0 | Used for Web graphics creation and enhancement. | |
| Visio 5.0 | Used for technical drawings. |
Performance evaluation was carried out according to quality procedures and a timeline defined by the in-house Enterprise Quality Assurance (EQA) program. The EQA testing philosophy focuses on enterprise-level support, system performance, and system recovery for client-server applications. The EQA strategy was to stress-test servers and the network, using the expected real-world transaction mix, at transaction volumes approximately ten times the peak volumes expected for the production site. The stress-test covered both server and network performance.
This section describes the test methods, provides samples of performance evaluations for servers and the network, and defines the network rating criteria used.
Our goal in stress testing was to see if any of our code components or Windows NT services would fail if large numbers of order transactions were being posted to the Web servers. This was achieved by running a series of stress-tests, and creating performance reports from the measured data.
Stress testing was carried out, using our development servers, by first creating a SKU page to generate an order with randomly-selected product SKUs, then modifying the confirmation page code slightly to redirect back to the start of the same SKU page on completion. The resulting loop posted one order to the database each time it was completed, exercising all the associated components on the way.
Typical order transaction rates tested were approximately 1,500 orders per hour, with each order having one, two, or three items at random. The following diagram and code example illustrate the setup and the stress test script loop.
Figure 19: Posting Data from the End-use Machine to the Database
Stress Test Script Loop
The following were the scripts used in the various Active server pages to post the data continuously without user interaction.
----------OrderHandoffSKU46.asp----------
Dim leviathanURL
leviathanURL = "checkoutSKU46.asp"
leviathanURL = leviathanURL & "?mscssid=" & Shopper_Id & "&use_form=1"
Response.Redirect(leviathanURL)
----------checkoutSKU46.asp-----------
In this page we really did not add any additional code but to simply submit the form as soon as the page is loaded.
-------xtl_PurchaseFormSKU46.asp----------
Dim pageRedirect
pageRedirect = "confirmationSKU46.asp?" & mscsPage.URLShopperArgs("order_id", rsOrder("Order_Id"))
call Response.Redirect(pageRedirect)
------confirmationSKU46.asp-----------
Response.Redirect("https://levdev1/smoke/sku46.asp")
Redirects to the beginning page SKU46.asp
Performance reports included Web server processor and memory utilization, ASP and Web service throughput, and processor and memory utilization for the database servers. Samples of these performance reports, with analysis, are shown below.
Network performance reports were based on transmitted data volumes, the number of “round trips” between server and browser, and the average frame size. These measurements were combined to create a network rating (see below) for each test, using the algorithm described in “Network Rating Criteria” at the end of this section.
The servers and network were stress-tested separately, using a similar transaction mix. In each case, the transaction mix was developed to represent the expected profile of production transactions. Transaction volumes were ramped up until either expected peak growth volumes were met, or the system failed.
Microsoft Performance Monitor was used to measure server performance, with Webload 3.0 scripts generating the test transactions. Network performance was measured using Optimal Application Expert and SQL Trace. The following table summarizes the transactions simulated and measurements for both server and network performance testing.
Table 7: Transactions and Measurements
| Test | Transactions simulated | Measurements |
| Server performance | Hit main page, Edit info, Change address, Submit
Change Quantity, Recalculate Purchase Customer Service (Order Status)—Item Status, USD link, Order list Customer assistance—Feedback about site, Submit feedback CSR—Search on name, Item status |
Individual server resource usage statistics (CPU, disk, memory, and network utilization).
Approximated minimum, maximum, and average times required to complete transactions under different stress levels. |
| Network performance | Same transaction mix as Server performance.
Network captures were repeated 3-5 times for each transaction to obtain an average. |
Bytes and packets transferred for each transaction including round trips required over network.
Response time breakdown—time spent in DB, IIS, Client, Network, and total time for each transaction thread. Client response times at different connection speeds and latencies. |
Testing included the Microsoft Direct Order Management application, and other customer assistance applications not covered in this white paper.
Server performance testing used a WebLoad 3.0 script to simulate approximately 10-times the expected load in the production environment. The script ran business transactions within a browser on a test client connected outside BIG/ip, in the same way that end-users connect to the application in production. Microsoft Performance Monitor was used locally on the IIS Server to measure processor utilization during the test.
Future plans to improve performance include replacing BIG/ip with the Microsoft Windows NT Load Balancing Service (WLBS), which is a component of the Windows NT Server 4.0 Enterprise Edition. This service allows you to combine the resources of up to 32 NT servers into a single cluster that can be referenced by a single IP address.
For more information on Microsoft’s WLBS (load balancing technology), refer to http://www.microsoft.com/NTServer/ntserverenterprise/exec/feature/WLBS/default.asp.
Application performance had no adverse effect on the servers. IIS processor and memory utilization was within an acceptable range, as were the database server processor and memory utilization.
Table 8: Sample Results—IIS Server Processor Utilization
| IIS Web Server Data | Minimum | Average | Maximum |
| System – % Total Processor Time | 12% | 78% | 90% |
| System – % Total Privilege Time | 5% | 40% | 49% |
| System – % Total User Time | 7% | 38% | 51% |
| Inetinfo – % Processor Time | 16% | 100% | 100% |
Analysis: Standards require System % Total Processor Time to average 80% or less for Web sites that reside on their own IIS Server or IIS Cluster. The average utilization (78%) observed during testing meets this standard.
Table 9: Sample Results—IIS Server Memory Utilization
| IIS Web Server Data | Minimum | Average | Maximum |
| Available Memory (in megabytes) | 913 | 914 | 919 |
| Pages/sec (in megabytes) | 1.5 | 4 | 22 |
| Inetinfo Process Private Bytes (in megabytes) | 26 | 31 | 29 |
| Inetinfo Process Working Set (in megabytes) | 28 | 32 | 33 |
Analysis: Memory counters observed during the above test exhibited no signs of memory leakage. The IIS–Working Set counter increased approximately five megabytes during the 20-minutes of test activity while the System–Available Memory and Inetinfo–Private Bytes counters remained constant throughout the test. The pages/sec counter averaged four megabytes, this shows no excessive paging was observed during the IIS Server Memory Test.
Table 10: Sample Results—IIS Server ASP & Web Service Utilization
| IIS Web Server Data | Minimum | Average | Maximum |
| Inetinfo - % Processor Time | 16% | 100% | 100% |
| ASP – Requests/Second | 1 | 3 | 9 |
| Web Service – Get Request/Second | 4 | 41 | 60 |
| Web Service – Post Request/Second | 1 | 2 | 5 |
Analysis: Based on the test results Microsoft Direct had average ASP – Request/Second of approximately 3 request/second and maximum of 9 request/second. The Web Service counters, Get Requests/Second and Post Request/Second averaged 41 request/second and 2 request/second respectively. SAT tested using approximately 10-times the amount of stress than the expected rate of the production environment.
Table 11: Sample Results—Database Server Processor Utilization
| Database Server Data | Minimum | Average | Maximum |
| System – % Total Processor Time | 1% | 2% | 4% |
| System – % Total Privilege Time | 1% | 1% | 2% |
| System – % Total User Time | 1% | 1% | 2% |
| Server – % Processor Time | 1% | 2% | 7% |
Analysis: System Acceptance Testing (SAT) standards require the System % Total Processor Time to average 80% or less for databases that reside on their own server. The average utilization (2%) observed during testing meets SAT standards. The Server – % Processor Time and other system processor counters exhibit extreme low averages.
Table 12: Sample Results—Server Memory Utilization
| Database Server Data | Minimum | Average | Maximum |
| Available Memory (in megabytes) | 834 | 850 | 866 |
| Pages/sec (in megabytes) | 0 | 1 | 19 |
| Process Private Bytes (in megabytes) | 798 | 799 | 800 |
| Process Working Set (in megabytes) | 87 | 103 | 119 |
Analysis: Memory counters observed during the above test exhibited no signs of memory leakage. The Server–Working Set counter increased approximately 35 megabytes during the 20-minutes of test activity while the System–Available Memory counter decreased the same amount. The Server–Private Bytes counter remained constant throughout the entire test. Therefore, it can be assumed that all memory consumed on the server was used for the Process.
For each task, network traffic was captured by a testing tool (Optimal Application Expert), and Microsoft SQL Server activity was recorded with SQL Trace. Seven meaningful tasks were selected for the Test Summary Report; they may represent the best and/or worst use of the network by the application.
The test client configuration used was a P-Pro200 with 128MB RAM, and 4GB HDD. Four iterations of each user action were run to find a median response time.
Due to the nature of the application, captures had to be recorded in two sets. One set of captures was recorded with the client on our back-end LAN (to capture client-to-IIS transmission times, not possible if the client goes through a proxy server). The second set was recorded with a client going through the proxy cluster (to access RegWiz components of the application). There were difficulties in reconfiguring the application to work on our back-end LAN only, and technical difficulties recording some of the network traffic for the proxy server testing.
The application scored a satisfactory network performance rating, using the in-house criteria. See “Network Rating Criteria” below for an example of calculating the network performance rating.
Client processing took the highest percentage of transaction duration in all of the transactions tested (expected). All transaction times were relatively low.
IIS processing for the Change Product Quantity and Change Customer Address functions was higher than average. A duration of this length does not pose any serious performance issues, but a code review of these areas could potentially lead to better IIS performance.
Since no existing documentation could be found on rating an application for network performance, in-house rating criteria was developed. Since the team was familiar with Microsoft Network Monitor and Optimal Application Expert, these tools were used to collect and analyze the network captures.
Network ratings were developed by identifying the key factors in network performance, taking measurements, and then weighting the results. Some common performance measures were omitted, either because they were judged to be application-specific, or because they did not take all the elements of performance into consideration. The tables below describe the key factors used, the weightings selected, and the performance measures that were omitted.
Table 13: Key Factors and Weightings
| Factor | Description | Weighting |
| Kbytes/Round Trip | Demonstrates how much data the application is moving in an average round trip. The higher the number, the more efficient the application is at transmitting data.
A round trip is a complete request-response transaction between client and server, not counting zero length ACKs. |
30% |
| Round Trips | This is the biggest factor in client response times in a slow link WAN environment. The smaller the number of round trips the more efficient the network is. | 30% |
| Average Frame Size | Tells us how efficiently the application is packing its shopping cart. The larger the frame size, the more efficient the application is. | 20% |
| Efficiency Score | This is a subjective rating based on factors such as frame padding, loading redundant meta-data, client caching, data access methodology, use of SQL Batching, offline capabilities, use of sp’s vs. dynamic SQL, persistent DB connections, use of local persistent storage, read only data, application performance anomalies, passive (e.g. “keep alive”) traffic, and so on. | 20% |
Reasons for weighting the criteria: Kbytes/Per Round Trip and Round Trip were weighed at a slightly higher percentage because they were directly involved in application performance (response time) on the network. Average Frame Size was weighted at a slightly lower percentage since it doesn’t affect application performance as drastically as the first two items, but is still a good indicator of how efficient an application is. Since the Efficiency Score is the only subjective measurement, it was weighted at a lower factor to reduce any undue application bias.
Table 14: Performance Measures Omitted
| Measure | Reason for omitting |
| Total Kbytes | This is application-specific. Due to their nature, some applications may be required to send more data across the wire than others. |
| Payload vs. Overhead | Does take into consideration frame padding, and does not reflect applications that use a large number of small frames to transmit data. |
| Total Frames | This is application-specific. This is a direct correlation of the Total Kbytes. |
| Duration | Does not take into consideration client and server induced delays. |
The original objectives of the Microsoft Direct project were:
All of these objectives have been met.
Microsoft Direct successfully processes high daily order volumes for shoppers who wish to obtain their Microsoft products, such as software, hardware, and publications, directly from Microsoft. Microsoft Direct’s customer service application successfully allows consumers to query, change, and cancel their own orders, and has been responsible for successfully pushing back to the consumer most of the administrative effort previously handled by internal customer service reps.
Microsoft Direct has created a single infrastructure capable of supporting additional Tenants, fulfillment Vendors, and geographic regions by designing for scalability, recognizing the importance of evaluating future performance from the very beginning, and supporting the widest possible range of browser technologies to meet the needs of the Tenant’s customers.
Microsoft Direct clearly showcases Microsoft’s electronic commerce technology. It shows how Microsoft commerce technologies are readily deployable to meet enterprise needs—in this case a high-performance, complex site with high levels of integration with third-party solutions. And it demonstrates how an implementation based on Microsoft Site Server 3.0 Commerce Edition, Microsoft Windows NT, and Microsoft SQL Server 6.5, can be designed to scale to meet the needs of over 60,000 online order transactions per day.
Applies to: HTML with data decryption.
Symptoms: Long download times.
Cause: HTML comments that span multiple lines are causing Data Decryption errors.
Workaround: A patch has been developed that is supposed to fix the problem.
The options are either to remove the multiple lines from the HTML comments, or drop the patch on the client for testing purposes and implement a disclaimer.
Internet Explorer 4.5 for MAC should have this patch and is scheduled for a sign off on 12/11/98 and to be released online on 1/5/98.
Applies to: Microsoft Windows NT Server version 3.51; Microsoft Internet Information Server version 1.0.
Symptoms: When the World Wide Web Publishing Service cannot start automatically during Microsoft Windows NT boot, you will get the following event viewer error message:
HTTP could not initialize socket library.
The properties of the services in Microsoft Internet Service Manager are not available. When you start the World Wide Web Publishing Service and FTP Server service manually, you will get the following error message:
Data area passed to system call is too small.
Workaround: A workaround is to change the order of protocols listed in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock\Parameters\Transports registry key by moving the TCP/IP protocol to the top of the list. Another workaround is to uninstall and then re-install the Windows NT Option Pack.
Symptoms: On a Web site with a large number of concurrent users using Secure Sockets Layer (SSL), the client may randomly receive the following error message:
Unable to connect to '<Web site>' a connection with the server could not be established.
Refreshing the page can recover the session.
Cause: The more complex the page, the longer it takes to download the page; therefore, fewer people can enter the site at one time. If you have a site with complex pages, you will encounter this problem with only a small number of concurrent users more frequently than a site with simpler pages.
This problem arises because each individual object on a page creates a separate session to download this object to the client. By default, the SSL component has only sufficient cache to maintain 100 sessions. This limitation is associated with the schannel component (Schannel.dll), used for SSL/PCT.
Workaround: To increase the size of the SSL server cache, modify the following registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Symptoms:
Cause: The server is trying to return a MIME type back to the client that it doesn’t say it will accept, therefore, the response fails.
Workaround: Set MIME type on the client to not care about .asp and .txt files. Set Response.CacheControl=Public on all .asp pages.
Applies to: Windows NT SP4, IIS 4, Microsoft Proxy 2.0 when using SSL.
Symptoms: GPFs.
Workaround: Make the following registry changes:
Applies to: Microsoft Internet Information Server version 4.0. (From Microsoft Knowledge Base Article: Q192295).
Symptoms: Memory leaks occur when you use the Secure Sockets Layer. By tracking the amount of private bytes for Inetinfo.exe, you will see that, over time, private bytes increase.
Cause: The memory leak occurs on each client accessed over the HTTP connection. IIS fails to free the memory allocated by Schannel.dll.
Workaround: A supported fix that corrects this problem is now available from Microsoft, but has not been fully regression tested and should be applied only to systems experiencing this specific problem. If you are not severely affected by this specific problem, Microsoft recommends that you wait for the next Windows NT service pack.
To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix.
Applies to: Microsoft Internet Explorer version 4.01 for Windows 95; Microsoft Internet Explorer version 4.01 for Windows NT 4.0.
Symptoms: When you use Internet Explorer to connect to a secure Web site with 128-bit encryption, you may receive the following error message, or one similar to it:
“Internet Explorer cannot open the internet site URL:<> the downloaded file is not available. This could be due to your security language setting or because the server was unable to retrieve the requested file.”
or
“Internet Explorer cannot open the internet site URL: <> the connection to the server was reset.”
or
IEXPLORE caused an invalid page fault in module WININET.DLL at
0137:7023d550.
Registers:
EAX=00489ae0 CS=0137 EIP=7023d550 EFLGS=00010202
EBX=00000000 SS=013f ESP=0086ff38 EBP=00412044
ECX=00000000 DS=013f ESI=0047bdb0 FS=33e7
EDX=0000000f ES=013f EDI=004e25ec GS=0da6
Workaround: A supported fix that corrects this problem is now available from Microsoft, but has not been fully regression tested and should be applied only to computers experiencing this specific problem. To resolve this problem immediately, contact Microsoft Technical Support to obtain the fix. If you are not severely impacted by this specific problem, Microsoft recommends that you wait for the next service pack that contains this fix.
Symptoms: You may receive the following error message or one similar to it:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC SQL Server Driver][SQL Server] Login failed
//global.asa, line 27
Response object error 'ASP 0156 : 80004005'
Header Error
/include/error.asp, line 18
Cause: The HTTP headers are already written to the client browser. Any HTTP header modifications must be made before writing page content.
Workaround: Ensure Web sites are running in their own memory space.
Applies to: Microsoft Visual InterDev, version 6.0.
Symptoms: Attempting to use setSQLText() or setRecordSource() on a recordset that is bound to a stored procedure gives the following Microsoft ActiveX® Data Objects (ADO) error:
ADODB.Parameters error '800a0cc1'
ADO could not find the object in the collection corresponding to the name or ordinal reference requested by the application.
/kb/_ScriptLibrary/Recordset.ASP, line 456
Cause: The recordset sets its parameters before opening the recordset. Even though the database object has changed, the routine that sets the parameters is still called.
Workaround: There are two workarounds for this. (1) Use different recordset DTCs for the stored procedure and the new record source, or (2) do not set the parameter for the stored procedure in the Parameters tab. Instead, set the parameter programmatically. A good place to do this is in the onbeforeopen event. Note that if you use this workaround, you need to know which state your recordset is in so you can avoid setting the parameter(s) after changing the recordSource/SQLText.
In a DHTML page, setting the parameter programmatically will not work. Consider using two recordset DTCs.
Status: Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this bug and will post new information in the Microsoft Knowledge Base as it becomes available.
More information: Steps to reproduce behavior:
Recordset1.setSQLText("SELECT * FROM AUTHORS")
Applies to: Microsoft SQL Server, version 4.2.
Symptoms: A call to a stored procedure that in turn calls another stored procedure can, in some cases, generate error 925:
Maximum number of used databases for each query has been exceeded. The maximum allowed is %d.
Cause: Microsoft SQL Server is not correctly freeing the data structures used to maintain information for each database when the called stored procedure fails with a deadlock.
Workaround: Reestablish your connection to Microsoft SQL Server in order to get a new spid.
Status: Microsoft has confirmed this to be a problem in Microsoft SQL Server version 4.2. We are researching this problem and will post new information in the Microsoft Knowledge Base as it becomes available.
More information: Given two stored procedures, CALLED and CALLER, where procedure CALLED is called by procedure CALLER, error 925 will occur if:
Your server command (process id #%d) was deadlocked with another process and has been chosen as deadlock victim. Re-run your command.
By Sean Emam, Steven C. Robertson, Kumar Parambir, Sunitha Devaguptapu, Mark Huck, Ted Hardy, Rajesh Patil, Stacie Croft, Wenbo Shao, Nalinabai Chelladurai, Ian Witucki, Mary Anne Blake, Mike Hartzog, and Bobby Kishore
Other contributions from: Roy Hirst, Mukesh Agarwal
Special Thanks to: Chris Cale, Beverly Jones
Microsoft Corporation
© 1999-2000 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for information purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, ActiveX, BackOffice, FrontPage, the Internet Explorer logo, JScript, Visual Basic, Visual C++, Visual InterDev, Visual SourceSafe, Visual Studio, Windows and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries/regions. Other products and Company names mentioned herein may be the trademarks of the respective owners.