In database Project Not able to resolve Circular References
In Database Project Not able to resolve circular reference. Still it is issue in VS. Also if we add more than 10 Project in a single database Solution then its goes as killing slow.
In our situation, we create a commercial application using a database project. We have a standard shared core set of tables and procs; and a client-bespoke part. We use a DACPAC of the standard part as a database reference in a database project and then add additional bespoke tables and procs as necessary. Some of these tables are of nesscity referered to from the standard part, even if only as SELECT *. This results in numerous SQL71502 warnings, which we are unable to fix. Ideally, we could generate either stubs for the bespoke tables known to exist - with a property other than build so that warnings are resolved but the bespoke tables are not included in a built DACPAC, or we could include a DACPAC of a template client project in our standard project so that the warnings go away.
Erik Ciccarone commented
Agreed, It is very common practice to create Views within a DB to point to tables/views in other DBs on the same server to avoid having DB Names scattered throughout your SP code. Then creating a solution that contains all the DBs to organize your DB code for source control can easily create the circular reference occurances between the DBs. If you are serious about letting developers manage DB Projects in Visual Studio, there needs to be a way to configure/disable the blocking created with this error condition.
Madhu Addepalli commented
It is time that something is done to support circular references between database projects. We recognize that having circular dependencies between databases is not ideal. However SQL server allows it and Visual Studio DB projects throws an error when we try to add a circular reference between two DB projects in the same solution. This is a bigger problem when there is a DB view requiring the reference as it result in SQL03006 errror causing the build to fail making the solution unusable.
Overcoming this limitation is crucial to make DB projects a viable option for database source control in the long term.
The various workarounds suggested in MSDN forums far are far from ideal:
1) Creating a third DB project and include objects that require circular reference
2) Manage references using static .dbschema file