Go To TechNet Home Page
| Updated: March 12, 1996 | Go To TechNet Home Page |
Presented by: Craig Goren
Craig Goren is president of Clarity Consulting, Inc., a Chicago
based consulting firm and Microsoft Solution Provider.
Clarity Consulting, Inc
Suite 2201
1212 North LaSalle
Chicago, IL 60610
Tel (312) 266-6639
Fax (312) 266-1006
InterNet: cgoren@claritycnslt.com
CompuServe: 72773,1062
© 1995 Clarity Consulting, Inc.
Introduction
Reusable Code Modules
Overview of Architecture Model
Back End
Front End
More Information, Please
There are many articles and seminars on the evolving theory of building solid client-server architectures. MIS managers and application developers, though, are often left with the overwhelming responsibility of choosing from a myriad of alternatives-planning a client-server application architecture involves many more choices than a traditional mainframe centralized processing environment. These choices need to work together properly, coexist with legacy systems, and provide needed functionality now and in the future.
This session will take a more practical than theoretical approach by demonstrating a complete and robust client-server decision support application architecture that incorporates products like Microsoft® Visual Basic® programming system, Microsoft SQL Server™ client-server database management system, Microsoft Windows NT™ operating system, and Microsoft Office Suite. It will leave the listener with a recommended, proven starting point that can be adapted to other environments.
It will cover business versus presentation logic, data warehousing, security, transaction processing, stored procedures, performance tuning, and database layout. It will provide reusable code and a sample application as well.
In order to "jump start" your development efforts, this seminar presents recommendations based on generalizations and personal opinion. You should recognize it as such and evaluate the applicability of all information to your own environment and system needs.
Most companies choose a decision support system (DSS) as their first foray into client-server-architecture. This is usually a wise choice, because it allows the IS department to become familiar with the new technology under the following conditions:
Organizations often build their first GUI-based applications on file sharing-based DBMSs like Microsoft Access database management system. These applications are not subject to the same requirements or planning as mainframe applications because they are labeled as "departmental," which really doesn't mean "has only a few users" as much as it means "it's PC-based, we can play it by ear."
The user base of these applications quickly skyrockets, and the corresponding maintenance and administrative tasks grow accordingly. The application becomes widely successful and is subject to numerous kludgy enhancements. Yearly maintenance costs are outrageous, often requiring a full-time resource or more. The cost of redeployment on a server-based DBMS is high as well, because the original development team never considered that the application would eventually need to be upsized. Everyone becomes afraid to kill "the beast".
Hopefully, this presentation will show that a little more effort can not only lay a solid foundation for future systems development, but will also be excellent opportunity to become familiar with client-server technology.
This seminar includes reusable code for a Visual Basic, SQL Server, and Microsoft Excel spreadsheet environment.
In addition to being a part of the presentation materials, all code can be found on CompuServe in the VBPJFOR forum in Section 13 - Client-server, of which I am the Sysop.
A set of Visual Basic APIs that plug into a project and allow access to an ODBC data source, with full error handling and asynchronous query execution support.
A set of Visual Basic APIs and a SQL Server stored procedure that plug into a project and supports dynamic application security. Requires VBODBC.
A set of Visual Basic APIs that plug into a project and automate the task of setting up OLE Automation (Microsoft's strategic object technology) Microsoft Excel pivot tables. Requires VBODBC.
An MDI Visual Basic and SQL Server project template that demonstrates this DSS application architecture. Requires VBODBC, VBSEC, and VBEXCEL.
The architecture incorporates the following characteristics:
VBDSS is an MDI Visual Basic and SQL Server project template that demonstrates the decision support architecture concepts of this presentation. It is designed to provide a sample shell of all the presentation concepts for easy modification to your own specification.
It utilizes and requires the other reusable components of this presentation: VBODBC, VBSEC, and VBEXCEL. It also utilizes the pubs database as the source for its DSS table.
1. VBDSS.MAK Visual Basic project make file
2. VBDSS.BAS Visual Basic code module
3. VBDSS1.FRM Visual Basic project MDI container form
4. VBDSS2.FRM Visual Basic project "New SnapShot Manager" child form
5. VBDSS3.FRM Visual Basic project "SnapShot" child form
6. VBDSS.SQL SQL Server pubs script
7. (Requires other files from VBODBC, VBSEC, and VBEXCEL libraries.)
1. Log on to SQL Server as sa and execute the VBDSS.SQL script. This will:
2. Log on to SQL Server as sa. Execute the VBSEC.SQL script against the pubs database. This will install the sp_security stored procedure, used by VBSEC to query user security rights.
3. Install an ODBC data source on the client workstation that points to the SQL Server.
4. If the SQL Server supports only integrated security, you will need to create Windows NT accounts for the SQL Server users dss_manager, dss_rep, and dss_programmer with passwords the same as their IDs.
5. Verify that Microsoft Excel 5.0 exists on the client workstation.
1. Start the application. Choose your SQL Server data source. Log on as dss_rep with password dss_rep.
2. A MDI form appears with a single child form, the New SnapShot Manager. This form manages the client requests for server "SnapShots," or result sets. The stored procedure sp_dss_states was used to populate the States list box.
3. Notice how the "Detail" radio button is disabled, because the dss_rep user doesn't have access to the corresponding stored procedure, sp_dss_detail.
4. Click the SnapShot button. A child form is created, the sp_dss_sum stored procedure is executed, the result set is loaded into an OLE Automation workbook, and the results are displayed in a grid.
5. The Pivot Fields list box lists all the pivot fields in the pivot table. The Orientation combo box shows the value of the Orientation property for the select pivot field. Try changing the pivot fields' orientation value and notice the changes reflected in the grid.
6. Try logging on with the dss_manager and dss_programmer IDs, and notice how the client application reacts dynamically to their server security rights.
A data repository (DR) is a relational picture of the data residing in the organization's on-line transaction processing (OLTP) systems. There are a number of benefits from operating DSS applications against a data repository:
The data repository should contain two layers. Each layer may contain any number of tables. Physically, each layer can reside on any number of servers including the OLTP servers. In practice, it usually makes the most sense to dedicate a SQL Server, separate from the OLTP server, and store both layers on this new server.
The new data repository doesn't have to be created all at once. Instead, the data repository requirements for the next 3-5 years should be designed and the data repository should evolve, driven by the prioritized needs of the end-user applications.
The data repository should contain proper primary and foreign key relationships. SQL is not as powerful when operating against non-relational data. Do it right!
Data Repository Model
The data warehouse layer contains a normalized picture of the enterprises data for a given period of time. It is called the data warehouse because, like a wholesaler, it provided data in bulk to other services and not the end user.
It contains consolidated business entities, and is not tuned for specific end-user applications. It should be refreshed in batch at regular intervals. Since the data may come from many different sources, the data warehouse build pass should rigorously convert the data to a consistent enterprise-wide view. This may involve intensive normalization and validation of denormalized data.
The data warehouse build pass will be specific to your environment. Often specialized gateway products (e.g. SNA Server or MDI Gateway) or custom server-based applications are required to migrate data from legacy production environments to SQL Server.
SQL Server version 6.0 supports two key pieces of functionality to support this batch process. The replication server will migrate production data automatically at regular intervals from certain data sources. And SQL Scheduler and stored procedure cursor support will enable complicated data migration to occur all within the context of SQL Server, without the need to build custom Windows NT services in C.
The data mart is built from the data warehouse in a second batch pass. The data marts are designed for specific end-user applications-often they are designed as a single table "one-stop shopping" client data source. It is called a data mart because, like a retailer, it provides data packaged the way the end user would like to see it.
For example, where an application request for data might involve a four-table join against the data warehouse, it might only involve a single data mart table.
All end-user and DSS application access to the data repository should be in the form of stored procedures, which must be approved and tested by the DBA. This will prevent runaway queries on the server. More on this later.
Since the data warehouse and data mart are both built in SQL Server, the data mart can be refreshed from the data warehouse with SQL Server stored procedures invoked at regular intervals.
More and more, we will see a move to a three-tiered client-server model. Three-tiered products are currently new, expensive, and proprietary. This presentation's architecture leverages some of the advantages of a true three-tiered model with a mainstream DBMS product, SQL Server.
All access to the server should be in the form of stored procedure calls. These functions are elementary business processes: a process which leaves the database in a consistent, valid state before and after execution (i.e. a "unit-of-work").
A single business function will be encapsulated in a single stored procedure. All commit/rollback is handled on the server. That is, a transaction will not span multiple client calls. However, one call may implement multiple SQL statements. For example, a "create customer" call may involve a series of validations not defined in the database schema.
The stored procedure should implement as much data validation logic as is possible, so that data validation rules are secured and managed on the server.
Complicated stored procedures can make use of new SQL Server specific functionality: T-SQL cursors, macro stored procedures, etc.
The stored procedure should call BEGIN TRAN. After executing every SQL statement, the stored procedure should check for an error with the global @@ERROR variable. If an error occurred, the stored procedure should ROLLBACK the transaction and RETURN. If the stored procedure completes successfully, it should COMMIT the transaction.
The advantages of using stored procedures exclusively for data access include:
This model works well in a DSS environment, but sometimes complex OLTP functions can't be implemented this way due to limitations in server functionality. For example, it may not be possible to create a complex "create order" transaction that involves many line items with a single stored procedure call.
Security should be purely an administrative task. The goal of the security model should be to maintain bullet-proof security while minimizing administrative maintenance requirements.
Ideally we need to secure more than just raw data: we need to secure the way the data is manipulated (i.e., secure the verbs as well as the nouns).
If possible, SQL Server should be configured with "integrated" security. This will allow client applications to leverage Windows NT security administration, and enable the users to have to remember one less password. Unfortunately, at the moment it requires that you have a Windows NT domain and are running named pipes. This restriction will become more relaxed in the future.
The guest login should be disabled. There are few reasons to allow guest access to the DBMS.
Stored procedures: single point of database entry
Users should be denied access to all SQL Server objects except stored procedures. The advantages of this include:
Stored procedures should be categorized based on business functionality, and access assigned to the appropriate user groups.
Client-side applications need to query the server for security information so they can enable and disable appropriate GUI functionality. It's inconvenient for a user to receive an error from the server because the user's logon doesn't have permission to execute a particular stored procedure.
The following procedure should be installed in all databases requiring client-side data access:
/* VBSEC.SQL */
/* This proc looks at the user_id of the current conn */
/* and returns a list of stored procs in the current db */
/* that the user has permission to execute */
/* This proc can be used by client application to retrieve */
/* information to determine whether or not client-side */
/* functionality should be enabled/disabled. */
/* Craig Goren 01/08/95 */
/* Internet: cgoren@claritycnslt.com */
/* CIS: 72773.1062 */
IF EXISTS (SELECT * FROM sysobjects WHERE id =
object_id('sp_security'))
begin
DROP procedure sp_security
print "Old procedure dropped."
end
GO
create procedure sp_security AS
begin
/* if sa/dbo, the return everything */
if USER_ID() = 1
begin
select o.name
from sysobjects o
where o.type = 'P' /* only get SPs */
order by o.name
return 0
end
/* begin "normal" user case */
/* find everything you or your alias owns */
select o.name
from sysobjects o,
sysusers u
where o.uid = u.uid
and o.type = 'P' /* only get SPs */
and o.uid = user_id() /* current user */
UNION
/* find everything you or your alias has been */
/* explicitly granted execute privliges on */
select o.name
from sysprotects p,
sysusers u,
sysobjects o
where p.uid = u.uid /* join */
and p.id = o.id /* join */
and action="[unarchived-media]" /* execute */
and protecttype=205 /* grant */
and p.uid = user_id() /* current user */
UNION
/* find everything you or your alias' group has been */
/* explicitly granted execute privliges on */
select o.name
from sysprotects p,
sysusers u,
sysobjects o
where u.gid = p.uid /* join */
and p.id = o.id /* join */
and action="[unarchived-media]" /* execute */
and protecttype=205 /* grant */
and u.uid = user_id() /* current user */
UNION
/* find everything the PUBLIC group has been */
/* explicitly granted execute privliges on */
select o.name
from sysprotects p,
sysobjects o
where p.uid = 0 /* PUBLIC */
and p.id = o.id /* join by object ID */
and action="[unarchived-media]" /* execute */
and protecttype=205 /* grant */
order by o.name
end /* sp_security */
go
print "New procedure added."
go
/* Grant execute privliges to public group. */
GRANT EXECUTE ON sp_security TO PUBLIC
go
print "Execute privliges granted to PUBLIC."
go
This SQL script can also be found in the file VBSEC.SQL. When executed, the sp_security stored procedure will return a list of all stored procedures within the database that the user has permission to execute. The client-side application can use this list to predetermine what stored procedures a user can execute. Note that it doesn't take into account any ownership qualifications (i.e. it assumes that there won't be multiple stored procedures names with different owners within the same database).
The Visual Basic application uses a multiple document interface (MDI) container. After logging the user on to the DBMS, the application displays only one child form, called the "SnapShot Manager."
This form allows the user to select a particular chunk of data to retrieve from the server into a new child form, called a "SnapShot." The SnapShot Manager should allow the user to filter and select a level of detail on concepts such as customer, product, location, time, sales rep, etc. The form enables and disables functionality based on server security settings.
Once the user has made a selection and directed the application to take a snapshot, the SnapShot Manger form loads a new child SnapShot form and passes the user's selection.
The newly created SnapShot form runs a stored procedure via ODBC against SQL Server to retrieve a result set that corresponds to the user's selection. It creates an instance of a Microsoft Excel workbook, and loads the result set into a pivot table in the workbook. Each SnapShot form has its own workbook "linked" to it.
The SnapShot form then allows the user to view the multidimensional result set, abstracting the complexities of the pivot table from the user but leveraging its computational power.
Front-End Overview
The user's selection from the SnapShot Manager form should invoke a single paramaterized stored procedure call on the server.
The types of snapshot result sets that are brought down to a SnapShot form should be carefully thought out. The application should be designed so the user needs to take additional snapshots infrequently. For example, if the users are regional managers, then a snapshot might contain all data for a particular region, so that a user need only take one snapshot to get all his or her pertinent data.
Performance should also be considered. Taking the SnapShot can often be a lengthy step, since it involves a server-based query, data retrieval, and the creation of a new OLE object. In general, the SnapShot result set should be about 100 rows, with 1000 rows as an upper limit. Although Microsoft Excel can handle >30,000 rows easily, the length of time it takes to place that amount of rows in a worksheet via OLE is usually unacceptable.
Users will quickly learn the SnapShot concept, and be able to understand how to make the application perform best for their needs.
Be creative with the SnapShot filtering and drill-down selection mechanism. Outline controls, such as the TList custom control from Bennet-Tec, are a good way of allowing the user to select from a hierarchy.
Once the SnapShot is selected, a child SnapShot form is created to manipulate and present the result set to the user. The SnapShot form creates a Microsoft Excel object through OLE automation and loads the result set into a pivot table. Note that we are using automation to manipulate the pivot table, and this does not require the use of the OLE custom control (MSOLE2.VBX).
Microsoft Excel pivot tables allow the Visual Basic application to manipulate the result set without executing another SQL statement or requiring complex Visual Basic calculation code. Pivot tables are much more flexible and faster than SQL. The pivot table object model is extremely powerful, and is documented very well in the Office Developer's Kit (ODK).
This architecture provides a lot of the benefits of emerging multidimensional on-line analytical processing (OLAP) database servers with a mainstream product, Microsoft Excel. Instead of storing data in a proprietary format on the server, it is stored in a standard relational format.
The most difficult part of using pivot tables through Visual Basic is setting them up with data. The VBEXCEL library takes care of this for you.
I personally do not like placing any source code in Microsoft Excel Visual Basic for Applications or using Microsoft Excel Visual Basic for Applications exclusively as the front-end (bypassing Visual Basic version 3.0 entirely). I prefer the tight control over the client environment and application distribution that Visual Basic version 3.0 provides. Microsoft Excel applications are often accidentally broken by end-users doing things they are not supposed to. Microsoft Excel does not provide a good environment for team development.
There are several bugs when using Visual Basic version 3.0 and OLE Automation. You should check the TechNet CD or Microsoft Knowledge Base for the latest list. One of the more notorious is a GPF that will eventually occur when using nested OLE "dot" calls. For example, the call:
xlMyWorkSheet.Range(Cells(3,4), (Cells(5,6))
should be replaced with the equivalent, but less elegant:
xlMyWorkSheet.Range("C4:E6")
The way you present the snapshot data on the Visual Basic child form will vary from application to application- it should be customized to your user's requirements. It should take advantage of the flexibility of the pivot table, and allow the user to rotate data, drill down, change row/column order, etc.
It should allow the user to view the data in both table and chart form, and allow the user to view both on screen and printer. Graphing VBX tools include First Impression by Visual Tools and ChartFX by Software FX. Table tools include Formula One by Visual Tools and Spread/VBX by Farpoint Technologies.
Unfortunately, the most obvious choice, Microsoft Excel itself, is not suitable. In order to display a dynamic Microsoft Excel table or chart with a Visual Basic version 3.0 container, you need to use OLE in-place activation. In-place activation, however, doesn't work as advertised right now with Visual Basic version 3.0 and Microsoft Excel. For example, Visual Basic version 3.0 has very little control over the visual characteristics of the workbook and a nasty bug causes Alt-Tab to lock the system. Microsoft has indicated on CompuServe that these bugs in the MSOLE2.VBX control will probably not be fixed until Visual Basic version 4.0.
VBEXCEL is a Visual Basic library that provides an easy method of setting up and retrieving a handle to a Microsoft Excel 5.0 pivot table created from the results of a SQL statement. It also includes all Microsoft Excel Visual Basic for Applications constant declarations.
It requires the use of a VBODBC data source. To use VBEXCEL with a different data source, see the in-line comments on what changes need to be made.
1. VBEXCEL.BAS A Visual Basic module
2. VBEXCEL.XLS A Microsoft Excel template file that is used for pivot tables.
1. VBEXCEL_OpenAppObj() - Initializes Microsoft Excel for OLE Automation.
2. VBEXCEL_OpenPivotWorkbook() - Executes a SQL statement, places the results in a Microsoft Excel pivot table, and returns an OLE handle to the pivot table in the form of a global variable (since Visual Basic can't SET a passed object variable). Multiple workbooks can be opened within the application.
3. VBEXCEL_WorkBookShow() - Should be used before any OLE automation calls to a workbook. Makes it visible and active, which some properties and methods require. Also performs check to make sure Microsoft Excel is ready to be automated.
4. VBEXCEL_GetRangeStr() - Creates a valid range string (e.g. "A5:F12") from row and column integer values. Helpful because of a bug in Visual Basic when the Excel Cells() method is used as a parameter to another Microsoft Excel method.
5. VBEXCEL_WorkBookHide() - Should be used after OLE Automation calls. Hides the workbook from the GUI so the user can not interact with it from within Microsoft Excel.
6. VBEXCEL_ClosePivotWorkbook() - Closes the given workbook and deletes the temporary file. You still need to set all your workbook object variables to Nothing.
7. VBEXCEL_CloseAppObj() - Shuts down Microsoft Excel if no workbooks are open. You still need to set all your application object variables to nothing.
VBEXCEL Function Flowchart
1. Add VBEXCEL.BAS to your project.
2. Copy VBEXCEL.XLS into the application directory.
3. Follow the instructions later in this presentation and add the VBODBC files to your project.
4. Have the Visual Basic application connect to a data source.
5. Call VBEXCEL_OpenAppObj to initialize Microsoft Excel and OLE.
6. Call VBEXCEL_OpenPivotWorkbook to create a new pivot table from a SQL statement.
7. Assign the global variables (VBEXCEL_NextPivotTable et. al.) to your own, since Visual Basic can not pass object handles as parameters to functions.
8. Manipulate the workbook with VBEXCEL_WorkBookShow, VBEXCEL_GetRangeStr, VBEXCEL_WorkBookHide, and your one OLE Automation calls.
9. Close the workbook with VBEXCEL_ClosePivotWorkbook. You still need to set all your own workbook object variables to "Nothing".
10. Close the application with VBEXCEL_CloseAppObj. You still need to set all your own application object variables to "Nothing".
One of the most confusing choices when designing a Visual Basic database application is choosing the data access API. The options for Visual Basic to SQL Server can be summarized as follows:
1. Bound data control.
2. Data access objects (DAO) with updatable dynasets.
3. DAO with non-updatable dynasets and SQL_PASSTHROUGH.
4. DB Library or an abstraction thereof, such as VBSQL.VBX or SQL Sombrero by Sylvan Faust.
5. Call the ODBC API directly.
I usually rule out the first three because of the lack of low-level control over the DBMS and poor performance they provide. They may, however, be suitable for a small number of users or no future need to support server-specific functionality.
A more interesting choice is between ODBC and the native DBMS API, DB-LIB. VBSQL and SQL Sombrero are probably easier to develop with than direct ODBC calls and do not sacrifice any server-based functionality or performance.
However, a carefully constructed Visual Basic abstraction of the ODBC API can be developed once and shared by all developers. This is what the VBODBC library included with this presentation does.
ODBC provides the following advantages over the native API:
This choice depends on the existence of a good ODBC driver, of which until recently there were few. ODBC is enjoying widespread industry support, however, and will only mature-it's an investment that will last.
You can expect, however, products that abstract multiple DBMSs as an object model (as opposed to an API) to eventually mature. Right now we have products that operate well against only one DBMS (like SQL Sombrero for SQL Server, and Oracle Objects for Oracle), or products that operate poorly against many DMBSs (like Jet), but we do not yet have the best of both worlds.
VBODBC is a Visual Basic library that provides an easy method of accessing data from an ODBC data source. It has the following characteristics:
1. VBODBC.BAS Visual Basic module
2. VBODBC1.FRM Visual Basic logon form
3. VBODBC2.FRM Visual Basic query executing form
1. VBODBC_OpenDatabaseDialog() - Establishes an ODBC database connection, prompting the user for connection information.
2. VBODBC_OpenSqlStmt() - Executes a SQL statement.
3. VBODBC_GetNextRow() - Retrieves another row of the SQL statement's result set. The row is retrieved into a variant array parameter, with each element corresponding to the equivalent column number. Element 0 contains all column values separated by tabs.
4. VBODBC_CloseSqlStmt() - Closes the SQL statement.
5. VBODBC_CloseDatabase() - Closes the database connection.
VBODBC Function Flow Chart
1. Add VBODBC.BAS, VBODBC1.FRM, VBODBC2.FRM to your project.
2. Verify that you have a proper ODBC data source configured.
3. Follow the function flowchart within your code. Note that only one SQL statement and one database connection can be active at a time, so that you don't have to maintain any handles.
4. Inspect the global structure VBODBC_LastErr if you encounter an error.
5. Inspect the global structure VBODBC_ColDesc for a description of the last SQL statements columns.
The front-end application should not "hard-code" security administration into the application. Instead, the system as a whole should be secure regardless of whether or not a user has access to a client executable. When security administration is performed on the server, the client applications should adjust dynamically to reflect these changes, enabling and disabling controls that correspond to server functionality. Code should never have to be recompiled because security administration has taken place.
The GUI facilitates calls to server-based stored procedure business functions. The fact that the GUI enables or disables controls depending on the logon is merely convenience and good interface design. However, even if a user manages to get access to a control they shouldn't, the security of the system will not be compromised. In addition, security and database integrity is not compromised even if a user attempts to invoke business functions from other tools (e.g. Microsoft Access or ISQL).
When several stored procedures are associated with one business function, SQL Server user groups should either be given access to all its SPs or none. It is safe to assume, therefore, that the front-end need only to check the first SP for access to determine whether or not the user has permission on a particular business function.
If a user does not have access to any business function of a MDI SnapShot child form, it is best to disable the control on the SnapShot Manager form that initiates the load of the child form.
VBSEC is a Visual Basic library that provides an easy method of inquiring whether or not a user has execute privileges on a particular SQL Server stored procedure. It requires the use of VBODBC and the sp_security stored procedure.
1. VBSEC.BAS Visual Basic module
2. VBSEC.SQL SQL Server sp_security stored procedure script
1. VBSEC_InitSecurity() - Retrieves from the server, with sp_security, a list of stored procedures that the current VBODBC user connection can execute.
2. VBSEC_ExecSecurity() - Given a stored procedure name, returns true if the current VBODBC database connection is able to execute it.
1. Add VBSEC.BAS to your project.
2. Follow the instructions earlier in this presentation and add the VBODBC files to your project.
3. Have the Visual Basic application connect to a data source.
4. Make sure the stored procedure sp_security has been installed in the data source's database.
5. Call VBSEC_InitSecurity to initialize security and receive server stored procedure security parameters.
6. Call VBSEC_ExecSecurity whenever the application needs to determine whether the database connection has execute privileges on a stored procedure.
© 1995 Microsoft Corporation.
THESE MATERIALS ARE PROVIDED "AS-IS," FOR INFORMATIONAL
PURPOSES ONLY.
NEITHER MICROSOFT NOR ITS SUPPLIERS MAKES ANY WARRANTY, EXPRESS
OR IMPLIED WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE
ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO
NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION
MAY NOT APPLY TO YOU.
NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR
ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL INCIDENTAL, DIRECT,
INDIRECT, SPECIAL, AND LOSS PROFITS. BECAUSE SOME STATES/JURISDICTIONS
DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES
THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT'S
AND ITS SUPPLIERS' ENTIRE LIABILITY IN ANY MANNER ARISING OUT
OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE SHALL
NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |