May 19, 2015 at 1:51 pm
john.leediii (5/19/2015)
Hakim, we did try suppressing the errors (71562,71502,72014,72045,70558,71558,71005,71561) - they still show up in the Error List, even if prefixed with SQL.
Yes, looks like you can only suppress warnings, not errors. However, another thing you can try is to set the "Build Action" property on individual files to "None", that will prevent those errors from showing up for the files treated such.
Hakim Ali
www.sqlzen.com
May 19, 2015 at 4:02 pm
hakim.ali (5/19/2015)
john.leediii (5/19/2015)
Hakim, we did try suppressing the errors (71562,71502,72014,72045,70558,71558,71005,71561) - they still show up in the Error List, even if prefixed with SQL.Yes, looks like you can only suppress warnings, not errors. However, another thing you can try is to set the "Build Action" property on individual files to "None", that will prevent those errors from showing up for the files treated such.
That will definitely stop those errors, but you can't do that if it's a critical proc/view that the app needs in order to function. You'll need the DB reference to get those to work properly if they're failing.
May 19, 2015 at 7:29 pm
Nice job, dealing with circular references in SSDT is a PITA!
July 21, 2015 at 3:12 am
Great post! We've been through a similar migration process and reading this has been reassuring that we probably did the right thing!
But let's say someone did need to publish a change to DB2 and so you created the DB2 solution with stubs for referenced objects on DB1 -> DB12.
Then, say, DB2 did need to change the type of a column, or the name of a column, or drop a column that is still referenced in lots of stored procedures, but its value has become meaningless over time (e.g. IsActive = 1 but inactive rows are now archived, so the whole table has a value of 1 here).
Do you have a process of keeping the stubs in sync with the real DB projects? Or of publishing this change across both DBs?
Second question: Is your DB6 (say) stub for the DB2 solution the same as the DB6 stub for the DB1 solution? As more and more databases are put into full projects, do you find you'll end up with pretty much a "full" stub project of table definitions and empty procedures?
August 5, 2015 at 2:20 pm
gdavies2002 (7/21/2015)
Do you have a process of keeping the stubs in sync with the real DB projects? Or of publishing this change across both DBs?Second question: Is your DB6 (say) stub for the DB2 solution the same as the DB6 stub for the DB1 solution? As more and more databases are put into full projects, do you find you'll end up with pretty much a "full" stub project of table definitions and empty procedures?
No, I do not have a process to keep stubs in sync. So far, DB1 is the only project that we develop against, the others are fairly static. If we should need a real project for DB2 etc, we will create one and the syncing process will be manual because the changes are few and far between.
Hakim Ali
www.sqlzen.com
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply