SQL Server Performance

.NET Framework 3.5 connection to SQL Server 2008

Discussion in 'SQL Server 2008 General Developer Questions' started by gsalunkhe, Dec 20, 2010.

  1. gsalunkhe New Member

    HiHow the .NET Framework 3.5 makes connection to SQL Server 2008. What is the actual architecture of making connection.Regardsgsalunkhe
  2. satya Moderator

    Welcome to the forums.
    I believe a tour on .NET section on MSDN will get you more information, you may refer to http://msdn.microsoft.com/en-us/library/bb822049(v=vs.90).aspx.
    Further here are few references from SQL BOL (documentation) on how it works;
    Beginning with SQL Server 2005, SQL Server features the integration of the common language runtime (CLR) component of the .NET Framework for Microsoft Windows. This means that you can now write stored procedures, triggers, user-defined types, user-defined functions, user-defined aggregates, and streaming table-valued functions, using any .NET Framework language, including Microsoft Visual Basic .NET and Microsoft Visual C#.
    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.
    By default, a SQL Server process that connects out to Windows acquires the security context of the SQL Server Windows service account. But it is possible to map a CLR function to a proxy identity, so that its outbound connections have a different security context than that of the Windows service account.
    In some cases, you may want to impersonate the caller by using the SqlContext.WindowsIdentity property instead of running as the service account. The WindowsIdentity instance represents the identity of the client that invoked the calling code, and is only available when the client used Windows Authentication. After you have obtained the WindowsIdentity instance, you can call Impersonate to change the security token of the thread, and then open ADO.NET connections on behalf of the client.
    After you call SQLContext.WindowsIdentity.Impersonate, you cannot access local data and you cannot access system data. To access data again, you have to call WindowsImpersonationContext.Undo.
    I hope the above helps...

Share This Page