Using Visual Studio 2015, and our C# app solution includes a database project, used mostly as source control for SPs and such.
Recently we added a second database we host locally in the instance, and so one or two of our SPs now includes a line of sql like:
select * from shareddb.dbo.sometable;
This upsets the build, generates an error like:
SQL71562: Procedure: [dbo].[MySP] has an unresolved reference to object [SharedDB].[dbo].[sometable].
(the "error" is mostly harmless, we can still run, but we don't like generating errors and ignoring them, would rather fix it!)
Apparently the fix is to create something called a .dacpac for SharedDB, a file extracted from the database in SSMS that contains a description of everything in SharedDB including sometable. That is fine.
Then you go to the DBProj in the solution explorer, there's a Reference node, you right-click on that to add a database reference, and point to the .dacpac and fill out other info, and with luck that will make the SQL71562 go away.
Right?
(A braver person than I would already have tried it!)
My question is a little more meta - where do I put the .dacpac so that everyone on the project has it and also avoids the errors? I guess I could host it within the DB project itself, right along side the source for the SPs and all, so it too is source-controlled?
Is that right?
Thanks,
Josh
