| title | description | author | ms.author | ms.date | ms.service | ms.topic | helpviewer_keywords | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Programming Extended Stored Procedures |
Database Engine Extended Stored Procedures - Programming |
VanMSFT |
vanto |
03/14/2017 |
sql |
reference |
|
[!INCLUDE SQL Server]
Important
[!INCLUDEssNoteDepFutureAvoid] Use CLR integration instead.
In the past, Open Data Services was used to write server applications, such as gateways to non-SQL Server database environments. [!INCLUDEmsCoName] [!INCLUDEssNoVersion] does not support the obsolete portions of the Open Data Services API. The only part of the original Open Data Services API still supported by [!INCLUDEssNoVersion] are the extended stored procedure functions, so the API has been renamed to the Extended Stored Procedure API.
With the emergence of newer and more powerful technologies, such as distributed queries and CLR Integration, the need for Extended Stored Procedure API applications has largely been replaced.
Note
If you have existing gateway applications, you cannot use the opends60.dll that ships with [!INCLUDEssNoVersion] to run the applications. Gateway applications are no longer supported.
In earlier releases of [!INCLUDEssNoVersion], extended stored procedures (XPs) provided the only mechanism that was available for database application developers to write server-side logic that was either hard to express or impossible to write in [!INCLUDEtsql]. CLR Integration provides a more robust alternative to writing such stored procedures. Furthermore, with CLR Integration, logic that used to be written in the form of stored procedures is often better expressed as table-valued functions, which allow the results constructed by the function to be queried in SELECT statements by embedding them in the FROM clause.
Common Language Runtime (CLR) Integration Overview
CLR Table-Valued Functions