如何检测SQLCLR中处于只读SqlContext（如SqlFunction）？

好问题！你提到的堆栈回溯方法确实能实现需求，但它有两个明显的短板：一是遍历堆栈帧加反射检查的性能开销不小，二是如果调用链有多层方法，你还得判断哪一层的特性才是决定当前上下文权限的关键。其实有几个更优的方案，分情况来看：

情况1：检查当前方法是否标记为只读 #

如果你的目标是确认当前正在执行的方法本身带有[SqlFunction(DataAccess = DataAccessKind.Read)]（或更严格的DataAccessKind.None），那完全不用折腾堆栈，直接获取当前方法的特性就行：

using System.Reflection;
using Microsoft.SqlServer.Server;

public static void MyMethod()
{
    var currentMethod = MethodBase.GetCurrentMethod();
    var sqlFunctionAttr = currentMethod.GetCustomAttribute<SqlFunctionAttribute>();
    
    bool isReadOnly = false;
    if (sqlFunctionAttr != null)
    {
        // None 是比 Read 更严格的只读模式（不允许任何数据访问）
        isReadOnly = sqlFunctionAttr.DataAccess == DataAccessKind.Read 
                  || sqlFunctionAttr.DataAccess == DataAccessKind.None;
    }
    
    // 根据isReadOnly执行后续逻辑
}

这个方法性能好很多，因为只需要反射当前方法，不用遍历整个调用栈。

情况2：检查整个SQLCLR上下文的只读状态（含上层调用者） #

如果你的方法可能被其他SQLCLR方法调用，需要判断当前整个执行上下文是否处于只读模式（比如上层方法标记了只读，当前方法没标记但继承了这个权限），那堆栈回溯是可行方向，但可以优化：

不用遍历所有堆栈帧，只需要找到第一个带有SqlFunctionAttribute或SqlProcedureAttribute的方法（因为SQLCLR的入口点一定是这些标记过的方法），然后检查它的DataAccess属性：

using System.Diagnostics;
using System.Reflection;
using Microsoft.SqlServer.Server;

public static bool IsInReadOnlyContext()
{
    if (!SqlContext.IsAvailable)
    {
        // 不在SQLCLR环境里，按需返回结果
        return false;
    }

    var stackTrace = new StackTrace();
    foreach (StackFrame frame in stackTrace.GetFrames())
    {
        var method = frame.GetMethod();
        
        // 检查是否是SQL函数
        var funcAttr = method.GetCustomAttribute<SqlFunctionAttribute>();
        if (funcAttr != null)
        {
            return funcAttr.DataAccess == DataAccessKind.Read 
                || funcAttr.DataAccess == DataAccessKind.None;
        }

        // 检查是否是SQL存储过程
        var procAttr = method.GetCustomAttribute<SqlProcedureAttribute>();
        if (procAttr != null)
        {
            return procAttr.DataAccess == DataAccessKind.Read 
                || procAttr.DataAccess == DataAccessKind.None;
        }
    }

    // 如果找不到入口点属性，可根据业务需求默认返回只读或可写
    return true;
}

另外还有一种“试探式”的方法，适合你确实要执行写操作的场景：尝试执行一个需要写权限的操作，比如调用SqlContext.Pipe.SendResultsStart（这个在只读上下文里会抛出特定异常）。这种方式避免了先检测再执行的冗余，也不会有竞态问题（SQLCLR上下文权限在执行期间不会变化）：

using Microsoft.SqlServer.Server;

public static bool CanPerformWriteOperations()
{
    if (!SqlContext.IsAvailable)
        return false;

    try
    {
        // 尝试启动结果集发送——这个操作在只读上下文里会失败
        using (var testRecord = new SqlDataRecord(new SqlMetaData("TestCol", System.Data.SqlDbType.Int)))
        {
            SqlContext.Pipe.SendResultsStart(testRecord);
            SqlContext.Pipe.SendResultsEnd();
        }
        return true; // 可以执行写操作
    }
    catch (System.InvalidOperationException ex)
    {
        // 捕获只读上下文的特定异常
        if (ex.Message.Contains("read-only context"))
        {
            return false; // 处于只读上下文
        }
        throw; // 其他异常重新抛出
    }
}

总结一下 #

• 仅检查当前方法标记：用MethodBase.GetCurrentMethod()直接获取特性是最优解；
• 检查整个上下文权限：优化后的堆栈回溯（找第一个入口点方法）比全栈遍历高效；
• 要执行写操作时：试探式执行更直接，避免冗余检测。

内容的提问来源于stack exchange，提问作者Sören Kuklau