> I have a application (Net Framework 2.0) connect to SQL Server 2005
> through SQL Client. When I run application (without debug in VS 2005
[quoted text clipped - 6 lines]
>
> How to resolve this problem?
In the topic for SqlConnection.Open, I found this note:
The .NET Framework Data Provider for SQL Server requires the Security
permission with "Allows calls to unmanaged assemblies" enabled
(SecurityPermission with SecurityPermissionFlag set to UnmanagedCode)
to open a SqlConnection with SQL Debugging enabled.
Exactly what this means, I don't know. You may be better off asing in a
.Net group about the gory details.

Signature
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Mary Chipman [MSFT] - 13 Nov 2008 18:45 GMT
What it means in a nutshell is that the ability to debug into SQL
Server is a potential attack vector, which is turned off by default.
You have to have a CLR security policy in place that explicitly grants
this permission to the caller, which is why everything works fine up
to that point. The SecurityPermissionFlag is an enumeration that
specifies access flags for the object the client application was
attempting to debug into. There's a code example in the Help topic for
SecurityPermissionFlag, or for a more complete explanation, see Don
Box's intro topic "The Security Infrastructure of the CLR Provides
Evidence, Policy, Permissions, and Enforcement Services" at
http://msdn.microsoft.com/en-us/magazine/cc188939.aspx.
--Mary
>> I have a application (Net Framework 2.0) connect to SQL Server 2005
>> through SQL Client. When I run application (without debug in VS 2005
[quoted text clipped - 16 lines]
>Exactly what this means, I don't know. You may be better off asing in a
>.Net group about the gory details.