Scribd
Upload
15 views

SQL CLR: Context Connection True

SQL CLR allows for stored procedures and triggers to be written in .NET languages like C# and VB.NET. Code written in these languages is compiled into CLI assemblies and registered with the database. It can then be invoked from SQL Server. The .NET Framework runtime is hosted directly by SQL Server rather than Windows. This allows .NET code to access SQL Server data using ADO.NET or enhanced ADO.NET providers to connect without creating new database sessions.

Uploaded by

Mayur Mandrekar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
15 views

SQL CLR: Context Connection True

SQL CLR allows for stored procedures and triggers to be written in .NET languages like C# and VB.NET. Code written in these languages is compiled into CLI assemblies and registered with the database. It can then be invoked from SQL Server. The .NET Framework runtime is hosted directly by SQL Server rather than Windows. This allows .NET code to access SQL Server data using ADO.NET or enhanced ADO.NET providers to connect without creating new database sessions.

Uploaded by

Mayur Mandrekar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 1

SQL CLR

Main article: SQL CLR

Microsoft SQL Server 2005 includes a component named SQL CLR ("Common Language
Runtime") via which it integrates with .NET Framework. Unlike most other applications that
use .NET Framework, SQL Server itself hosts the .NET Framework runtime, i.e., memory,
threading and resource management requirements of .NET Framework are satisfied by
SQLOS itself, rather than the underlying Windows operating system. SQLOS provides
deadlock detection and resolution services for .NET code as well. With SQL CLR, stored
procedures and triggers can be written in any managed .NET language, including C# and
VB.NET. Managed code can also be used to define UDT's (user defined types), which can
persist in the database. Managed code is compiled to CLI assemblies and after being verified
for type safety, registered at the database. After that, they can be invoked like any other
procedure.[30] However, only a subset of the Base Class Library is available, when running
code under SQL CLR. Most APIs relating to user interface functionality are not available.[30]

When writing code for SQL CLR, data stored in SQL Server databases can be accessed using
the ADO.NET APIs like any other managed application that accesses SQL Server data.
However, doing that creates a new database session, different from the one in which the code
is executing. To avoid this, SQL Server provides some enhancements to the ADO.NET
provider that allows the connection to be redirected to the same session which already hosts
the running code. Such connections are called context connections and are set by setting
context connection parameter to true in the connection string. SQL Server also provides
several other enhancements to the ADO.NET API, including classes to work with tabular
data or a single row of data as well as classes to work with internal metadata about the data
stored in the database. It also provides access to the XML features in SQL Server, including
XQuery support. These enhancements are also available in T-SQL Procedures in
consequence of the introduction of the new XML Datatype (query, value, nodes
functions).[31]

You might also like