--------------------------------------------------------Microsoft(R) SQL Server OLE DB Provider 7.00.459 Readme File --------------------------------------------------------(c) 1998 Microsoft Corporation. All rights reserved.

This document provides late-breaking or other information that supplements the M icrosoft SQL Server OLE DB Provider documentation. -------CONTENTS -------1. PRODUCT DESCRIPTION 2. TECHNICAL NOTES ---------------------1. PRODUCT DESCRIPTION ---------------------SQLOLEDB, the Microsoft SQL Server OLE DB provider, exposes interfaces to consum ers wanting access to data on one or more SQL Servers. -----------------2. TECHNICAL NOTES -----------------2.1 Changes to SQLOLEDB Properties Note the following changes in the SQLOLEDB properties: * The DBPROP_INIT_DATASOURCE property is now used to specify the name of a server running SQL Server. It is no longer used to specify a database name. * The DBPROP_INIT_CATALOG property is now used to specify the initial database. * The DBPROP_INIT_LOCATION property is no longer supported. * The DBPROP_AUTH_INTEGRATED property is now supported. If DBPROP_AUTH_INTEGRATED is set to SSPI , integrated security is used. If it is set t o null BSTR pointer, SQL Server security will be used. * The SSPROP_AUTH_TRUSTEDCONNECTION property is no longer supported. * The DBPROP_INIT_MODE provider specific property is no longer supported. 2.2 If a command is attempted on a connection that already has a command outstanding , SQLOLEDB creates another connection to process the new command if the followin g conditions are true: * DBPROP_MULTIPLECONNECTIONS is set to VARIANT_TRUE. * The first command did not produce a rowset, or it is not using a server curso r. * The connection has no active transaction. If there is an active transaction on the connection then the attempt to execute a second command returns E_FAIL. If there is no active transaction but DBPROP_MU

LTIPLECONNECTIONS is VARIANT_FALSE, the attempt to execute a second command retu rns DB_E_OBJECTOPEN. Transactions and locking are managed by SQL Server on a per connection basis. I f a second connection is generated, the commands on the separate connections do not share locks. Care must be taken to ensure one command does not block another by holding locks on rows requested by the other command. 2.3 To improve performance by reducing network traffic, SQLOLEDB does not automatica lly derive parameter information unless ICommandWithParameters::GetParameterInfo or ICommandPrepare::Prepare is called before executing a command. This means th at SQLOLEDB will not automatically: * Verify the correctness of the datatype specified with ICommandWithParameters:: SetParameterInfo. * Map from the DBTYPE specified in the accessor binding information to the corre ct SQL datatype for the parameter. Applications will recieve possible errors or loss of precision with either of th ese methods if they specify datatypes that are not compatible with the SQL datat ype of the parameter. To ensure this does not happen, the application should: * If hard coding ICommandWithParameters::SetParameterInfo, ensure that pwszDataS ourceType matches the SQL datatype for the parameter. * If hard coding an accessor, ensure that the DBTYPE being bound to the paramete r is of the same type as the SQL datatype for the parameter. * Code the application to call ICommandWithParameters::GetParameterInfo so that the provider can dynamically obtain the SQL datatypes of the parameters. This wi ll cause an extra network round-trip to the server. 2.4 DBPROP_CHANGEINSERTEDROWS can only be set to VARIANT_TRUE if the rowset is using a keyset-driven cursor.