Развертывание объектов проекта базы данных Visual Studio в схему, отличную от "dbo" - PullRequest
0 голосов
/ 15 октября 2019

У меня следующий сценарий.

У меня есть хранимая процедура SQLCLR в проекте базы данных Visual Studio. Это должно быть не в схеме dbo, а в foo. Как я видел, невозможно использовать другую схему для хранимой процедуры SQLCLR при использовании функции публикации Visual Studio.

Так что я должен обернуть ее. Теперь у меня есть два сценария.

Один для добавления сборки:

CREATE ASSEMBLY [MyAssembly]
FROM 'MyAssembly.dll';
GO

И другой для добавления хранимой процедуры в базу данных:

CREATE PROCEDURE [foo].[MyProc](@param NVARCHAR(10))
    AS EXTERNAL NAME MyAssembly.ClassName.MyProc
GO

Но теперь яполучить ошибку из-за неразрешенной ссылки на MyAssembly. Я думаю, это потому, что все (SQLCLR proc, T-SQL wrapper proc, скрипт добавления сборки) в одном проекте и ссылка на него.

Что может быть лучшим способом для развертывания хранимой процедуры SQLCLRпо моей схеме в базе? Если бы можно было добавить это непосредственно в реализацию SQLCLR, было бы здорово.

Заранее спасибо.

Ответы [ 2 ]

1 голос
/ 15 октября 2019

На самом деле, это должно быть не проблема. Начиная с Visual Studio 2012, есть возможность установить схему для объектов-оболочек T-SQL. В свойствах проекта перейдите на вкладку «Настройки проекта», а справа в разделе «Общие» есть текстовое поле с надписью: «Схема по умолчанию». Это схема, используемая для объектов-оболочек T-SQL (я обычно не использую развертывание SSDT, поэтому я просто подтвердил эту информацию в Visual Studio 2015 - я знаю, я знаю, мне действительно необходимо обновить).

Это также упоминалось в моем ответе: Схема для хранимой процедуры CLR во время развертывания

Если используемая версия Visual Studio / SSDT не имеетвозможность установить схему ИЛИ , если вам нужно поместить объекты в несколько схем, тогда вы сможете просто добавить сценарий пост-развертывания T-SQL, который перемещает объектына желаемую схему. При добавлении сценария T-SQL и установке свойств «после развертывания» (или чего-то подобного) он будет вставлен в конец сгенерированного сценария публикации.

Если это только небольшое количестводля объектов, в которые не будут введены новые объекты, вы можете сделать явные операторы для каждого объекта:

ALTER SCHEMA [foo] TRANSFER [dbo].[MyProc];

Если это большое количество объектов и / или новые объекты будут добавляться время от времени, и вы не будетеЕсли вы хотите не забыть добавить их в этот сценарий включения после развертывания, вы можете циклически перебирать список объектов, связанных с этой сборкой, чтобы создать сценарий динамического SQL, который может перемещать их все без каких-либо затруднений, кроме имени сборки. закодированы (и технически это может даже быть динамическим с использованием переменных MSBuild / SSDT):

DECLARE @SQL NVARCHAR(MAX) = N'';

SELECT @SQL += N'ALTER SCHEMA [foo] TRANSFER [dbo].'
               + QUOTENAME(obj.[name]) + N';' + NCHAR(0x0D) + NCHAR(0x0A)
FROM   sys.assembly_modules amd
INNER JOIN sys.assemblies asm
        ON asm.[assembly_id] = amd.[assembly_id]
INNER JOIN sys.objects obj
        ON obj.[object_id] = amd.[object_id]
WHERE  asm.[name] = N'Company.Area.Technology.ProjectName' -- do not use [ and ] here
AND    SCHEMA_NAME(obj.[schema_id]) = N'dbo'

PRINT @SQL; -- DEBUG (else, comment out)

EXEC (@SQL);
0 голосов
/ 15 октября 2019

Я мог бы решить это сам. Просто очень глупая ошибка ...

Название моей сборки имеет шаблон Company.Area.Technology.ProjectName. Если я пытался создать хранимую процедуру с этим, произошла ошибка, ожидающая точку.

CREATE PROCEDURE [foo].[MyProc](@param NVARCHAR(10))
    AS EXTERNAL NAME Company.Area.Technology.ProjectName.ClassName.MyProc
GO

Решение состоит в том, чтобы установить имя сборки между [].

CREATE PROCEDURE [foo].[MyProc](@param NVARCHAR(10))
    AS EXTERNAL NAME [Company.Area.Technology.ProjectName].ClassName.MyProc
GO

Это работает. Так что я могу обернуть процедуру CLR в свою собственную схему.

...