7 Appendix B: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows NT Server 4.0 operating system Service Pack 3 (SP3)

  • Windows 2000 Professional operating system

  • Windows 2000 Server operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows 11 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1: No applications or services in Windows make use of RDS Transport Protocol. In Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, RDS Transport Protocol support is included as an optional component for the primary purpose of maintaining backward compatibility with Windows SharePoint Services 1.0 clients.

<2> Section 1.3: No applications or services in Windows make use of RDS Transport Protocol. In Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, RDS Transport Protocol support is included as an optional component for the primary purpose of maintaining backward compatibility with Windows SharePoint Services 1.0 clients.

Note As of Windows 8 and Windows Server 2012, the RDS server has been removed from the Windows implementation of the RDS Transport Protocol. The RDS client is still available in the Windows implementation of the RDS Transport Protocol.

<3> Section 2.2.1.1: When used as a numeric value, WORD fields always use little-endian byte order.

<4> Section 2.2.1.1: When used as a numeric value, DWORD fields always use little-endian byte order.

<5> Section 2.2.1.1: LONG fields always use little-endian byte order.

<6> Section 2.2.1.1: ULONG fields always use little-endian byte order.

<7> Section 2.2.1.1: FLOAT fields always use little-endian byte order.

<8> Section 2.2.1.1: DOUBLE fields always use little-endian byte order.

<9> Section 2.2.1.1: The Microsoft implementation always sets RESERVEDBITs to %b0.

<10> Section 2.2.1.1: The Microsoft implementation always sets RESERVEDBYTEs to %x00.

<11> Section 2.2.1.2: Currently implemented RDS Transport Protocol messages do not make use of the type VT-UNKNOWN. The presence of the VT-UNKNOWN and VT-DISPATCH types allows for future extensibility by means of creating messages that make use of objects that expose different interfaces.

<12> Section 2.2.1.4: In the Windows implementation, SCODE2 typically identifies the root cause of the error represented by SCODE.

<13> Section 2.2.1.5: INTERFACEID is used as CLSID and, in typical cases, this is CLSID_CADORecordset, IMPLEMENTATIONID is set to adtgRecordSetGUID, and DATASTREAM is an adtgTablegram.

<14> Section 2.2.1.7: In the Windows implementation, if there is a disagreement between the value of ARRAYFEATURES and the datatype of the array, the ARRAYFEATURES value is used and the datatype is ignored.

<15> Section 2.2.2.1.1: RDS Transport Protocol always issues the HTTP Request with the following settings:

Method = "POST"

EndPoint = "/msadc/msadcs.dll/"

NameSpace = "RDSServer.DataFactory"

User-Agent = "ACTIVEDATA"

<16> Section 2.2.2.1.1: RDS Transport Protocol always sets Connection attribute to Keep-Alive and Cache-Control to no-cache, as specified in [RFC2616] section 14.

<17> Section 2.2.2.2.1: RDS Transport Protocol always sets Response Header fields of the response with Connection = "close" and server = "Microsoft-IIS/M.m", where "M" is replaced with the major version and "m" with the minor version of the Internet Information Services (IIS) server delivering the HTTP response.

<18> Section 2.2.2.3: The RDS Transport Protocol client always issues requests to the HTTP endpoint "<servername>/msadc/msadcs.dll". The RDS Transport Protocol server is always set to listen on the same endpoint.

<19> Section 2.2.2.3.1: For the RDS Data Factory Message Set, all messages use a namespace of "RDSServer.DataFactory".

<20> Section 2.2.2.4: In the Windows implementation, the rdsClientVersionName is always sent as "ADCCLientVersion". rdsVerMajor is set to "01" and rdsVerMinor is set to "06".

<21> Section 2.2.2.5.1: All messages in the RDS Data Factory Message Set have an exact value for rdsParamCountValue between 2 and 210. rdsParamCountValue cannot exceed 1024. Therefore, methods callable using the RDS Transport Protocol have fewer than 1024 parameters.

<22> Section 2.2.2.6: The rdsParameters are encoded in right-to-left order such that the last parameter in a method definition is the first occurrence of rdsNonGroupableParam or rdsGroupableParam in the rdsParameters component.

<23> Section 2.2.3: For the RDS Data Factory namespace, all messages use the following settings:

  • rdsPostURI is set to "RDSServer.DataFactory" or "AdvancedDataFactory". Both possible values are equivalent.

  • rdsMethodNameSpace is set to "/msadc/msadcs.dll/".

<24> Section 2.2.3.1: The rdsExecuteRequest message corresponds to two methods: Execute and Execute21. The Execute21 method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<25> Section 2.2.3.2: The rdsExecuteResponse message corresponds to two methods: Execute and Execute21. The Execute21 method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<26> Section 2.2.3.5:  The rdsSynchronizeRequest message corresponds to two methods: Synchronize and Synchronize21. The Synchronize21 method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<27> Section 2.2.3.6:  The rdsSynchronizeResponse message corresponds to two methods: Synchronize and Synchronize21. The Synchronize21 method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<28> Section 2.2.3.7:  The rdsSubmitChangesRequest message corresponds to the SubmitChanges method. This method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<29> Section 2.2.3.8:  The rdsSubmitChangesResponse message corresponds to the SubmitChanges method. This method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<30> Section 2.2.3.9:  The rdsConvertToStringRequest message corresponds to the ConvertToString method. This method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<31> Section 2.2.3.10: The rdsConvertToStringResponse message corresponds to the ConvertToString method. This method is not used by Windows. Its functionality is not routinely tested by Microsoft.

<32> Section 2.2.3.13.1: For the RDS Data Factory Message Set, the following special cases are used.

 rdsConnectionString = SQLConnectionString /
  OracleConnectionString / ShapeConnectionString /
  JetConnectionString
              
 SQLConnectionString = *(SQLKV ";")
  "Provider=SQLOLEDB" [".1"] *(";" SQLKV) [";"]
              
 OracleConnectionString = *(OracleKV ";")
  "Provider=MSDAORA" [".1"] *(";" OracleKV) [";"]
              
 ShapeConnectionString = *(ShapeKV ";")
  "Provider=MSDATASHAPE" [".1"] *(";" ShapeKV) [";"]
              
 JetConnectionString = *(JetKV ";")
  "Provider= Microsoft.Jet.OLEDB.4.0" [".1"] *(";" JetKV) [";"]
              
 SQLKV = DataSourceKV / UserIdKV / PasswordKV /
  InitialCatalogKV / ServerKV / DatabaseKV / uidKV / pwdKV /
  TrustedConnectionKV / OtherKV
              
 OracleKV = DataSourceKV / UserIdKV / PasswordKV /
  InitialCatalogKV / OtherKV
              
 ShapeKV = DataSourceKV / UserIdKV / PasswordKV /
  InitialCatalogKV / DataProviderKV / OtherKV
              
 JetKV = DataSourceKV / UserIdKV / PasswordKV /
  InitialCatalogKV / OtherKV
              
 ServerKV = "Server=" DataSource
              
 DatabaseKV = "Database=" Value
              
 InitialCatalogKV = "Initial Catalog=" Value
              
 uidKV = "uid=" UserId
              
 pwdKV = "pwd=" Password
              
 DataProviderKV = "Data Provider=" Value
              
 TrustedConnectionKV = "Trusted_connection=" Value
              
 OtherKV = Key "=" ( Value / QuotedValue )
              

SQLConnectionString

Subcontext

Meaning of the Value field

ServerKV or DataSourceKV

Specifies the name of a data store, and adheres to the constraints of the DataSource field.

DatabaseKV or InitialCatalogKV

Specifies the name of a database in the data store. A database name adheres to the constraints of the ConnectionStringIdentifier field. The data store can specify and enforce further restrictions on the database name.

UserIdKV or uidKV

Specifies the user name.

PasswordKV or pwdKV

Specifies the user password.

TrustedConnectionKV

Specifies if the default authentication is to be used. "Yes" designates that the RDS Transport Protocol server uses default authentication information. "No" designates that the user name for data store authentication is taken from UserIdKV or uidKV of rdsConnectionString and the password for data store authentication is taken from PasswordKV or pwdKV. For details on data store authentication, see section 3.3.5.

If the Value is "Yes", Integrated Authentication is used to authenticate against the data store.

ShapeConnectionString

Subcontext

Meaning of the Value field

DataProviderKV

Specifies which data store will provide the primary data.

When the value of the rdsConnectionString field supplied in the request is an instance of the ShapeConnectionString, the value in the rdsShapeCommandString field is parsed and processed according to the rules of the Shape command language, as described in section 3.3.5.2.4. Otherwise, the value of the rdsSQLCommandString field is a SQL-92 string (as specified in [FIPS127]) to be interpreted by the data store and not the RDS Transport Protocol server, with the exception of additional processing that occurs if applicable, as described by the rules in section 3.3.5.2.3.

<33> Section 2.2.3.13.1: The Microsoft implementation allows additional schemes to be used.

<34> Section 2.2.3.13.3: Windows will accept additional data types. If a FIXED-LEN-VTDATA-GROUPABLE or VAR-LEN-VTDATA-GROUPABLE is substituted for rdsExecuteOptions, the server will attempt to use Automation Argument Coercion to convert the data to VT-I4 LONG. If the conversion is successful, message processing proceeds normally. If the conversion is unsuccessful, an rdsMethodResponseError corresponding to a malformed request message is sent. For more information on Automation Argument Coercion, see [MS-OAUT] section 3.1.4.4.4.

<35> Section 2.2.3.13.3: For more information on the data described in the table, see [MSDN-EXMETHOD] and [MSDN-LOCKTYPE].

<36> Section 2.2.3.13.5: A handler string of "MSDFMAP.handler" specifies that the Microsoft supplied handler (MSDFMAP.DLL) is to be used. A handler string of "MSDFMAP.handler,sample.ini" specifies that the Msdfmap.dll handler is to be used and that the argument "sample.ini" is to be passed to the handler. The sample.ini file is expected to contain the information for replacing connection and query strings with the values provided in the sample.ini. Similarly, restrictions based on the current user (for example, data store access restrictions) can be enforced by the handler.

For example, if the client specifies "DataSource=AuthorDataBase" as the connection string, it might get translated to "Provider='sqloledb';User Id=a;Password=b;Initial Catalog='Northwind'". Similarly, a query like "AuthorIdOnly" might become "select au_id from authors".

<37> Section 2.2.3.13.6: Windows will accept additional data types. If a FIXED-LEN-VTDATA-GROUPABLE or VAR-LEN-VTDATA-GROUPABLE is substituted for rdsFetchOptions, the server will attempt to use Automation Argument Coercion to convert the data to VT-I4 LONG. If the conversion is successful, message processing proceeds normally. If the conversion is unsuccessful, an rdsMethodResponseError corresponding to a malformed request message is sent. For more information on Automation Argument Coercion, see [MS-OAUT] section 3.1.4.4.4.

<38> Section 2.2.3.13.6: The Windows implementation defines this flag in API as adcFetchUpFront.

<39> Section 2.2.3.13.6: The Windows implementation defines this flag in API as adcFetchBackground.

<40> Section 2.2.3.13.6: The Windows implementation defines this flag in the API as adcFetchAsync.

<41> Section 2.2.3.13.9: The rdsEncapsulatedData parameter always uses a TableGram to transmit RecordSets. Therefore, the syntax of rdsEncapsulatedData in the Windows implementation is as follows.

Name

Value

rdsEncapsulatedData

VT-DISPATCH ZEROBYTE adtgInterfaceId adtgImplementationId adtgTablegram

adtgInterfaceId

%x35.05.00.00.00.00.10.00.80.00.00.AA.00.6D.2E.A4

adtgImplementationId

%xB6.92.F2.3F.04.B2.CF.11.8D.23.00.AA.00.5F.FE.58

adtgTablegram

See section 2.2.3.14 for details.

<42> Section 2.2.3.13.13: A request with an rdsTableName parameter that contains the string value "[My Table]" is equivalent to a request with an rdsSQLCommandString that contains the string value "Select * from [My Table]".

<43> Section 2.2.3.13.14: Windows will accept additional data types. If a FIXED-LEN-VTDATA-GROUPABLE or VAR-LEN-VTDATA-GROUPABLE is substituted for rdsLCID, the server will attempt to use Automation Argument Coercion to convert the data to VT-I4 LONG. For more information on Automation Argument Coercion, see [MS-OAUT] section 3.1.4.4.4.

If the conversion is successful, message processing proceeds normally. If the conversion is unsuccessful, an rdsMethodResponseError corresponding to a malformed request message is sent.

<44> Section 2.2.3.14.1: In the Windows implementation, the version is fixed at %x00.00.

<45> Section 2.2.3.14.1: The Windows implementation of RDS Transport Protocol does not support big-endian byte order; little-endian byte order is used when interoperating with a Microsoft client or server.

<46> Section 2.2.3.14.1: The Windows implementation requires the non-Unicode format.

<47> Section 2.2.3.14.2: In the Windows implementation, the value of adtgRecordSetGUID is set at (0xb6, 0x92, 0xf2, 0x3f, 0x04, 0xb2, 0xcf, 0x11, 0x8d, 0x23, 0x00, 0xaa, 0x00, 0x5f, 0xfe, 0x58). The GUID is the class identifier of the FoxRowset object, which holds the RecordSets in the TableGram on the client side. A FoxRowset object is an object implemented on the Microsoft platform for the caching of data.

<48> Section 2.2.3.14.2: In the Windows implementation, adtgOriginalURL is a zero-length string. Both the client and server will ignore any non-empty value of this string.

<49> Section 2.2.3.14.2: In the Windows implementation, adtgFriendlyName is a zero-length string. Both the client and server will ignore any non-empty value of this string.

<50> Section 2.2.3.14.2: Windows regards 0 as the default value and takes the same behavior as 1 (adtgAsyncOptionsSync).

<51> Section 2.2.3.14.3.1: In the Windows implementation, the value of the GUID contained by adtgGUIDResultDescriptor is ignored. A server initializes it to (0xd2, 0xad, 0x63, 0xf6, 0x02, 0xeb, 0xcf, 0x11, 0xb0, 0xe3, 0x00, 0xaa, 0x00, 0x3f, 0x00, 0x0f).

<52> Section 2.2.3.14.3.1: The Windows implementation supports only adtgCursorSnapshot.

<53> Section 2.2.3.14.3.6: The following bit flags in adtgColumnDescriptorPresenceMap correspond to column properties of a database. The value of a particular bit defines whether the corresponding property is applicable to a column. For example, if a column supports the auto-increment property, then the fIsAutoIncrement flag is set to 1. On the other hand, if the database column does not support the auto-increment property, then the fIsAutoIncrement flag is set to 0.

  • fBaseSchemaName

  • fBaseCatalogName

  • fBaseTableColumnName

  • fBaseTableColumnOrdinal

  • fBaseTableOrdinal

  • fFriendlyColumnName

  • fIsAutoIncrement

  • fVariantDefaultValue

  • fDateTimePrecision

  • fComputeMode

  • fCollatingSequence

  • fCalculationInfo

  • fOctetLength

  • fIsUnique

  • fIsSearchable

  • fIsMultivalued

  • fIsCaseSensitive

<54> Section 2.2.3.14.3.6: The Windows implementation always omits the CollatingSequence field by setting its corresponding bit in the presence map to 0.

<55> Section 2.2.3.14.3.6: The Windows implementation always omits the ComputeMode field by setting its corresponding bit in the presence map to 0.

<56> Section 2.2.3.14.3.6: The Windows implementation always omits the DateTimePrecision field by setting its corresponding bit in the presence map to 0.

<57> Section 2.2.3.14.3.6: The Windows implementation always omits the VariantDefaultValue field by setting its corresponding bit in the presence map to 0.

<58> Section 2.2.3.14.3.6: The Windows implementation always omits the IsCaseSensitive field by setting its corresponding bit in the presence map to 0.

<59> Section 2.2.3.14.3.6: The Windows implementation always omits the IsMultivalued field by setting its corresponding bit in the presence map to 0.

<60> Section 2.2.3.14.3.6: The Windows implementation always omits the IsSearchable field by setting its corresponding bit in the presence map to 0.

<61> Section 2.2.3.14.3.6: The Windows implementation always omits the IsUnique field by setting its corresponding bit in the presence map to 0.

<62> Section 2.2.3.14.3.6: The Windows implementation always omits the OctetLength field by setting its corresponding bit in the presence map to 0.

<63> Section 2.2.3.14.3.7: In the Windows implementation, the "Background Fetch Size" PropertyId is also known as DBPROP_ADC_ASYNCHFETCHSIZE.

<64> Section 2.2.3.14.3.7: In the Windows implementation, the "Initial Fetch Size" PropertyId is also known as DBPROP_ADC_ASYNCHPREFETCHSIZE.

<65> Section 2.2.3.14.3.7: In the Windows implementation, the "Background Thread Priority" PropertyId is also known as DBPROP_ADC_ASYNCHTHREADPRIORITY.

<66> Section 2.2.3.14.3.7: In the Windows implementation, the "Batch Size" PropertyId is also known as DBPROP_ADC_BATCHSIZE.

<67> Section 2.2.3.14.3.7: The Windows implementation generates unique values using the following algorithm:

  • Each RecordSet is assigned a "Reshape Name", which is initialized to its alias as specified by the parentAlias or childAlias fields in the rdsShapeCommandString. (For more information about these fields, see section 3.3.5.2.4.) Any RecordSet that has no alias is assigned the default "Reshape Name" of "DSRowset".

  • Each unique "Reshape Name" is assigned a use count, which is initialized to 0 for all names, except "DSRowset", for which the use count is initialized to 1.

  • As each RecordSet is added to the adtgTablegram, this property is assigned according to the following algorithm:

    • If the RecordSet's "Reshape Name" has a use count of 0, the property is assigned the value of the "Reshape Name".

    • If the RecordSet's "Reshape Name" has a use count greater than 0, the property is assigned by concatenating the RecordSet's "Reshape Name", and the use count in decimal form. For example, if the "Reshape Name" is "Orders" and the use count is 2, the property would be set to the value "Orders2". Similarly, if the "Reshape Name" is the default value "DSRowset" and the use count is 3, the property would be set to the value "DSRowset3".

    • The use count of the RecordSet's "Reshape Name" is incremented. In this way, Windows generates unique values for this property.

<68> Section 2.2.3.14.3.7: In the Windows implementation, the "Update Resync" PropertyId is also known as DBPROP_ADC_UPDATERESYNC.

<69> Section 3.1.1.2.4: The Microsoft implementation always includes optional fields that are provided by the higher-level application.

<70> Section 3.2.2.1: The Windows client uses the request execution timer with a default time-out value of 60 seconds.

<71> Section 3.2.4.3: RDS Transport Protocol clientRecordSet change tracking allows an arbitrary number of changes to be compounded together and sent to the server as a single batch.

<72> Section 3.3.1.1: The list of client namespaces is maintained within the Component Object Model (COM) programming system (for more information, see [MS-DCOM]). The COM system maintains a registration database that behaves the same as the "SHOULD" in this paragraph.

<73> Section 3.3.2.1: A server that is running an applicable Windows Server release uses a SQL request execution timer with a default time-out value of 3 minutes.

<74> Section 3.3.3: Servers that are running applicable Windows Server releases listen on both TCP/IP port 80 and on TCP/IP port 443 by default. Administrators can change the port configuration of the HTTP server.

<75> Section 3.3.3: Servers that are running applicable Windows Server releases listen on the URI "http://<servername>/msadc".

<76> Section 3.3.5.1.1: The Microsoft RDS Transport Protocol server closes the HTTP connection when it receives a request that violates the handler specifications.

<77> Section 3.3.5.1.2: The RDS Transport Protocol server by default returns very limited error information to the client in order to not expose internal information in the error response.

<78> Section 3.3.5.1.2: The RDS server that is running an applicable Windows Server release always passes SQL-92 commands to the data store for processing.

<79> Section 3.3.5.2.1: The Windows implementation uses pluggable data providers on the server to communicate with data stores. Microsoft currently supports four primary providers: Microsoft OLEDB provider for Microsoft SQL Server, Microsoft OLEDB provider for Jet, Microsoft OLEDB provider for Oracle, and Microsoft OLEDB provider for Shape. All of these providers rely on the SQL-92 command language, as specified in [FIPS127]. The Shape provider allows the server to process Shape commands over the top of the SQL-92 commands.

<80> Section 3.3.5.2.2: The row set that exposes relation hierarchy enables dynamic data to be maintained. This means that changes in the child RecordSet are directly reflected in the parent RecordSet.

<81> Section 3.3.5.2.2: In the Windows implementation, RDS Transport Protocol data is produced and consumed on the client by the RDS.DataControl object. The RDS.DataControl object works with ADO RecordSet objects. ADO provides a facility for caching and maintaining the cached state of a data source on the client. It is this cache that maintains the batch of commands to update the server.

<82> Section 3.3.5.3: The RDS Transport Protocol server by default returns very limited error information to the client in order to not expose internal information in the error response.

<83> Section 3.3.5.4: The RDS Transport Protocol server by default returns very limited error information to the client in order to not expose internal information in the error response.

<84> Section 3.3.5.5: The Microsoft implementation of RDS Transport Protocol server always first uses the connection string to establish a connection to the data store before performing additional processing.

<85> Section 3.3.5.5: The RDS Transport Protocol server always submits the batch of SQL commands to the data store under a single transaction.

<86> Section 3.3.5.6: The Microsoft implementation of RDS Transport Protocol server always first uses connection string to establish a connection to the data store before performing additional processing.

<87> Section 3.3.5.6: The RDS Transport Protocol server by default returns very limited error information to the client in order to not expose internal information in the error response.

<88> Section 3.3.5.6: The RDS Transport Protocol server always submits the batch of SQL commands to the data store under a single transaction.

<89> Section 5.1: Windows implements an RDS handler mechanism. The main function of the handler mechanism is to allow the RDS Transport Protocol server to block a large number of inbound requests. Only very specific actions are allowed within the handler mechanism. For example, the handler can force all clients to use the same connection string to the data store, or only allow a certain SQL command to be executed.