Data Access from CLR Database Objects
A common language runtime (CLR) routine may easily access data stored in the instance of Microsoft SQL Server in which it runs, as well as data stored in remote instances. Which particular data the routine can access is determined by the user context in which the code is running. Access data from within a CLR database object by using the .NET Framework Data Provider for SQL Server, also referred to as SqlClient. This is the same provider used by developers accessing SQL Server data from managed client and middle-tier applications. Because of this, you can leverage your knowledge of ADO.NET and SqlClient in client and middle-tier applications.
.gif "ms131109.note(de-de,SQL.90).gif") Hinweis: |
|---|
| User-defined type methods and user-defined functions are not allowed to perform data access by default. You must set the DataAccess property of SqlMethodAttribute or SqlFunctionAttribute to DataAccessKind.Read to enable read-only data access from user-defined type (UDT) methods or user-defined functions. Data modification operations are not allowed from UDTs or user-defined functions, and throws exceptions at execution time if attempted. |
This section discusses only the specific functional and behavioral differences when accessing data from within a CLR database object. For more information about the features and functionality of ADO.NET, see the ADO.NET documentation included in the .NET Framework SDK.
The following table lists the topics in this section.
| Topic | Description |
|---|---|
Describes the context connection to SQL Server. |
|
Describes impersonating connections and connection credentials. |
|
Discusses the in-process specific SqlPipe, SqlContext, SqlTriggerContext, and SqlDataRecord objects. |
|
Describes how the new transaction framework provided in the System.Transactions namespace integrates with ADO.NET and SQL Server CLR integration. |
|
Explains how to enable XML serialization scenarios of CLR database objects inside SQL Server. |