Как наша база данных может вызвать сбой SqlPackage? (SQL72018)

Надеюсь, что кто-то еще столкнулся с этим, потому что Google возвращает только девять результатов для этой ошибки! Информация о SqlPackage все еще кажется немного скудной.

В настоящее время мы проходим процесс перехода к среде непрерывного развертывания. В рамках этого мы используем проекты баз данных для хранения схемы базы данных, а сервер сборки использует SqlPackage.exe для создания сценария обновления путем сравнения каждого проекта .файл dacpac с соответствующим шаблоном схемы база данных, размещенная на сервере.

На данный момент у нас есть шесть баз данных (с большим количеством впереди), и все они прекрасно работают, кроме одной, которая выдает следующую ошибку, когда SqlPackage моделирует "целевую" базу данных:

Ошибка SQL72018: триггер не удалось импортировать, но один или несколько из этих объектов существуют в исходном коде.

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

Мы собираемся начать удаление объектов из целевой базы данных и исходного проекта, чтобы увидеть, можем ли мы установить, является ли он размером или конкретным объектом схемы, но любые идеи и предложения в то же время были бы очень признательны!

Обновить

Я только что попытался удалить все триггеры из цели база данных, и теперь она выплевывает сценарий обновления без ошибок. Затем я попытаюсь удалить только половину из них, и посмотрим, смогу ли я сузить его до одного конкретного триггера. Я подозреваю, что это может быть просто Размер схемы, которая восходит к вопросу о памяти SqlPackage.

1 2
sql-server database ssdt database-project

1 ответ:

Хорошо .. все продумал.

Мы прошли через процесс отбрасывания триггеров, пока не сузили его до единственного триггера, который вызывал ошибку. Оказывается, с ним было что - то не так-кажется, что он должен быть прикреплен к таблице, но это не так (т. е. он не появляется в списке триггеров). Так что я предполагаю, что это незначительное повреждение вызвало сбой SqlPackage.

В случае, если кто-то сочтет это полезным, это скрипт, который я использовал для удаления диапазонов триггеров, которые помогли мне найти виновника:

Http://www.codeproject.com/Tips/662699/Drop-all-Triggers-belonging-to-any-schema-in-MS-SQ

Use ClaimsSqlPackageTest

DECLARE @SQLCmd nvarchar(1000) 
DECLARE @Trig varchar(500)
DECLARE @sch varchar(500)

Declare @count int = 0

DECLARE TGCursor CURSOR FOR

SELECT ISNULL(tbl.name, vue.name) AS [schemaName]
     , trg.name AS triggerName
FROM sys.triggers trg
LEFT OUTER JOIN (SELECT tparent.object_id, ts.name 
                 FROM sys.tables tparent 
                 INNER JOIN sys.schemas ts ON TS.schema_id = tparent.SCHEMA_ID) 
                 AS tbl ON tbl.OBJECT_ID = trg.parent_id
LEFT OUTER JOIN (SELECT vparent.object_id, vs.name 
                 FROM sys.views vparent 
                 INNER JOIN sys.schemas vs ON vs.schema_id = vparent.SCHEMA_ID) 
                 AS vue ON vue.OBJECT_ID = trg.parent_id

OPEN TGCursor
FETCH NEXT FROM TGCursor INTO @sch,@Trig
WHILE @@FETCH_STATUS = 0
BEGIN

SET @SQLCmd = N'DROP TRIGGER [' + @sch + '].[' + @Trig + ']'

If @count >= 155 AND @count <= 160 Begin
    EXEC sp_executesql @SQLCmd
    PRINT @SQLCmd   
End

Set @count = @count + 1

FETCH next FROM TGCursor INTO @sch,@Trig
END

CLOSE TGCursor
DEALLOCATE TGCursor
5