Share via

Guidelines and Limitations in Native XML Web Services

This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

The following guidelines and limitations apply to Native XML Web Services requests:

  • When a SOAP unnamed session (SOAP unnamed sessions exist for the duration of only one request) requests transaction notification and includes the BEGIN TRANSACTION statement but not the COMMIT TRANSACTION or ROLLBACK TRANSACTION statement, the server rolls back the transaction but does not include the rollback transaction notification node in the SOAP response.

  • Support for Native XML Web Services is only available on instances of SQL Server that are running on versions of the Windows operating system that support the HTTP API (Http.sys). If you try to deploy Native XML Web Services on an instance of SQL Server that does not meet this operating system requirement and does not support Http.sys, Data Definition Language operations will fail and no native listening will occur.

  • If the instance of SQL Server is running on Windows XP Professional, you may not be able to successfully create endpoints. For example, if Internet Information Services (IIS) is running, an attempt to run a CREATE ENDPOINT statement fails returning the following error: "An error ('0x80070020') occurred while attempting to register the endpoint 'endpointName'."

    This error indicates a process conflict between the instance of SQL Server and IIS occurs because IIS listens on port 80 under Windows XP. To work around this problem, do the following:

    • Stop the World Wide Web service

    • Retry running CREATE ENDPOINT by using a port number other than port 80.

  • You can configure endpoints to use multiple ports, but you cannot specify two ports of the same type. For example, you can specify one clear port and one SSL port, but not two clear ports or two SSL ports.

  • Table valued user-defined functions are not supported.

  • SOAP does not support exposing extended stored procedures as web methods.

  • You cannot disable non-HTTP endpoints (state for an endpoint can be set to disabled only for HTTP endpoints).

  • Although the SOAP specification explicitly disallows XML processing instructions in SOAP requests and responses, SQL Server does not enforce this restriction. If processing instructions (PIs) are present in the enveloping of a SOAP request, the server ignores them. If PIs appear within the contents of an XML parameter, they are persisted as part of the XML data. SOAP responses should not contain processing instructions unless they are part of a retrieved XML parameter. One implication of this behavior is that SOAP client applications might not accept an xml data type row instance value that contain PIs, or the applications might strip out PIs that are contained in the typed XML returned by SQL Server. If this is an important scenario, you can build Web services that convert any xml data types to NVarChar or VarBinary types before the service sends them back to SOAP clients.

  • For greater interoperability with Visual Studio 2005, make sure that any namespaces used in endpoint Web methods are different from any namespaces used with xml data type schemas that are also used on the endpoint.

  • WSDL results that are returned by an endpoint can include an XSD schema that is not valid, such as when a single namespace is imported more than once in either of the following scenarios:

    • The endpoint contains multiple parameters of XML type that reference different schema collections each of which defines the same namespace.

    • The endpoint contains a parameter of XML type that references a namespace URI predefined for use with Native XML Web Services in SQL Server. Predefined namespace URIs where this scenario might apply include those listed in the following table.


      Namespace URI