I want to build a dacpac of a SQL Server database. I used SSDT to import the database objects into a project. The build succeeded without any errors but has lots of warnings(more than 100) related to unsolved references.
The unsolved references point are due to the following:
Objects from other databases in the same server. (Warning SQL71562)
Objects from other databases from other SQL Server instances. (Warning SQL71562)
Objects referencing the same database itself where a 3-part naming convention was used [DatabaseName].[SchemaName].[ObjectName]. (Warning SQL71562)
Contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects. (Warning SQL71562)
The object definition [xxx].[#xyz] differs only by case from the object definition [xxx].[#xyz]. (SQL Warning: SQL71558)
Warning SQL71562: Computed Column: [#abc].[def] contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects:
I have tried deploying the build which has only warnings but the deployment didn't succeed.
There are a couple of issues to address here, the easiest ones are the case and 3-part names.
For the 3-part names, doing a find/replace in all *.sql files to replace [databasename].[dbo]. with [dbo]. and the various combinations of bracketed/non-bracketed items should suffice.
For case differences, if there aren't a lot of them, fix them. Otherwise, you can set the global ignore for that particular warning number.
External database references are going to be trickier - that requires either an external database reference (with a dacpac) or a pointer to another project that compiles. I find the dacpac easier just to start, but that's something you have to play with. I have some stuff on SSDT on my blog @ https://schottsql.com/all-ssdt-articles that might be helpful there. (note - the articles are old, but the concepts haven't changed that much)
For the remainder, you're likely going to have to address those on a case-by-case basis. Some might be because the object on which they depend uses that "same database, 3-part name" convention and will be resolved when that's changed. Some might be due to external references. Those are going to take some work to resolve. If the project builds successfully, you might be okay to try generating a script or publishing/comparing.