How could our database be causing SqlPackage to fail? (SQL72018)

Question

Hoping someone else has come across this, because Google returns only nine results for this error! Information about SqlPackage seems a little scant still.

We're currently going through the process of migrating to a continuous deployment environment. As part of this, we're using database projects to store database schema and the build server is using SqlPackage.exe to generate an upgrade script by comparing each project's .dacpac file with its associated schema template database that's hosted on the server.

We have six databases so far (with more to come) and they all work fine apart from one, which throws the following error when SqlPackage is modelling the 'target' database:

Error SQL72018: Trigger could not be imported but one or more of these objects exist in your source.

The only thing we can think of is that it's a problem with the size of the target database; perhaps SqlPackage is running out of memory? It's the largest database schema we have, so it's certainly feasible. If it's down to a memory limitation of SqlPackage, how do we go about increasing it?

We're going to start removing objects from the target database and the source project to see if we can establish whether it's down to size or a specific schema object, but any ideas and suggestions in the meantime would be greatly appreciated!

Update

I just tried removing all triggers from the target database, and now it spits out the upgrade script with no errors. Next I'll try removing only half of them, and see if I can narrow it down to one specific trigger. I suspect it may simply be the size of the schema, which goes back to the SqlPackage memory question.

Answer 1

Okay .. worked it out.

We went through a process of dropping triggers until we narrowed it down to a single trigger that was causing the error. Turns out that there was something rather wrong with it - it seems that it's meant to be attached to a table, but isn't (i.e. it doesn't appear in the triggers list). So I'm guessing this minor corruption caused SqlPackage to fail.

In case anyone finds it useful, this is the script I used to drop ranges of triggers, which helped me find the culprit:

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

Answer 2

Putting a trigger on a table that has the extended property 'microsoft_database_tools_support' is a simple way to produce this error. For example putting a trigger on the sysdiagrams table.

Apparently this extended property makes the object invisible to VS and the existence of a trigger on an invisible object is confusing. You can either make both objects visible by removing the microsoft_database_tools_support properties or make them both invisible by adding the property to the other object.

So in my example of putting a trigger named iut_sysdiagrams on sysdiagrams I'd use this:

EXEC sys.sp_addextendedproperty @level0type = N'SCHEMA' ,@level0name = [dbo] 
        ,@level1type = N'TABLE' ,@level1name = [sysdiagrams]
        ,@level2type = N'TRIGGER' ,@level2name = [iut_sysdiagrams]
        ,@name = N'microsoft_database_tools_support' ,@value = 1;