LINQ для DataTable в хранимой процедуре CLR - PullRequest
Новая
       16

LINQ для DataTable в хранимой процедуре CLR

8 голосов
/ 06 июля 2010

Кто-нибудь знает, возможно ли (и как) использовать LINQ для DataTable внутри хранимой процедуры CLR ?

Однако у меня нет проблем с использованием LINQ для DataTable в стандартном проекте WinForms; Я использую проект базы данных в VS2010 на SQL2005 и создаю хранимую процедуру:

(упрощенный листинг) 

[Microsoft.SqlServer.Server.SqlProcedure]
public static void ProcessReOrder()
{       
    using (SqlConnection conn = new SqlConnection("context connection=true")) { 
        SqlDataAdapter adapter = new SqlDataAdapter("database.dbo.OtherSp", conn);  
        DataTable table = new DataTable("ReOrder");
        adapter.Fill(table);

        var query = from t in table.AsEnumerable() 
                    where t.Field<int>("Id") > 1000 select t.Field<int>("Id");

    etc.....
}

Проблема в том, что AsEnumerable () - это метод расширения, и хотя я получил , используя ссылку на LINQ; это все еще не найдено.

Поиск в Google привел меня к мысли, что это связано с использованием ссылки на сущность LINQ (DLL), скрытой в структуре, однако, поскольку это проект БД, мы не можем добавлять ссылки на какие-либо библиотеки DLL на система; поле добавления справки ограничено несколькими выбранными сборками, и кнопка browse ... отсутствует.

Независимо от проблем с производительностью и т. Д., Я не хочу, чтобы вручную катил много ADO / T-SQL внутри моего .NET Stored proc; Я предпочитаю LINQ и возможность перемещать код на разные уровни / платформы БД. Поддерживается ли LINQ для DataTable внутри Stored Proc (я полагаю, что нет), или я совершенно не согласен с этим и должен кодировать с T-SQL?

1 Ответ

5 голосов
/ 30 декабря 2010

Я не уверен, что это поможет вам пройти весь путь, однако в SQL Server 2008 будет установлен System.Data.DataSetExtensions , чтобы вы могли ссылаться на него из своего проекта SQL CLR.Обратите внимание, что я вошел в систему как член фиксированной серверной роли sysadmin .

Сначала мне нужно было подготовить базу данных для загрузки небезопасной сборки.Я выполнил ALTER DATABASE dbname SET TRUSTWORTHY ON;, затем установил для владельца базы данных значение sa с помощью ALTER AUTHORIZATION ON database::dbname TO sa;.

Затем я извлек v3.5 сборки из GAC на моей рабочей станции, скопировавфайл в каталог хранения (скажем, c: \ temp) из C: \ Windows \ assembly \ GAC_MSIL \ System.Data.DataSetExtensions \ 3.5.0.0__b77a5c561934e089.

После этого я смог установить сборку с оператором CREATE ASSEMBLY [System.Data.DataSetExtensions] FROM 'C:\temp\System.Data.DataSetExtensions.dll' WITH PERMISSION_SET = UNSAFE;.

Когда вы закончите оператор, вы получите это дружеское напоминание: Предупреждение: сборка Microsoft .NET Framework'system.data.datasetextensions, версия = 3.5.0.0, культура = нейтральная, publickeytoken = b77a5c561934e089, processorarchitecture = msil.'Ваша регистрация не полностью протестирована в среде, размещенной на SQL Server, и не поддерживается.В будущем, если вы обновите или обслужите эту сборку или .NET Framework, ваша процедура интеграции CLR может перестать работать.Для получения более подробной информации обратитесь к электронной документации по SQL Server.

На этом этапе я смог сослаться на System.Data.DataSetExtensions в моем проекте SQL CLR, и я подтвердил, чтоAsEnumerable() обнаружен в экземпляре DataTable.

...