Comments
Sort by recent activity
Are your changes in source control? If not, there probably isn't an easy way to do this through SQL Compare. However, assuming your changes are in source control: If using Redgate SQL Source Control, check out: https://documentation.red-gate.com/soc5/common-tasks/working-with-migration-scripts But this feature is a bit tricky to use. Alternatively use the SQL Change Automation Visual Studio Plug-in (previously known as ReadyRoll). This will use a migrations driven approach to source control rather than a model driven approach, giving you more control over your deployment scripts: https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/sql-change-automation-projects For more info about state-based source control (SQL Source Control) and migration-based source control (SQL Change Automation project): http://dlmconsultants.com/model-vs-mig / comments
Are your changes in source control? If not, there probably isn't an easy way to do this through SQL Compare.However, assuming your changes are in source control:If using Redgate SQL Source Control,...
Yes - if a view tries to read from a table that doesn't exist the build should fail. / comments
Yes - if a view tries to read from a table that doesn't exist the build should fail.
Ah - now the order of this thread is messed up and the accepted answer is the answer to the wrong question! (-: / comments
Ah - now the order of this thread is messed up and the accepted answer is the answer to the wrong question! (-:
Don't use 3 part naming? Seems to be unnecessary assuming the table is on the same database. 3 part naming just makes your life harder. You can work around it if you must. Use the -TargetDatabase switch. https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/invoke-databasebuild Reason for error is SQL Change Automation will create a scratch DB with a guid for a name to test your code. Your 3 part naming obviously cries. If you use -TemporaryDatabaseName it will ensure SQL Change Automation uses your specified DB for the build. This is a pain though as you can now only run one build at a time. / comments
Don't use 3 part naming? Seems to be unnecessary assuming the table is on the same database. 3 part naming just makes your life harder.You can work around it if you must. Use the -TargetDatabase sw...
Sprocs are only compiled at run time so dependency issues aren't uncovered simply by building/deploying the DB. / comments
Sprocs are only compiled at run time so dependency issues aren't uncovered simply by building/deploying the DB.
In this scenario your database will not change simply by switching branches. The changes might appear as a conflict in the get latest tab? If not try using SQL Compare after you switch branches to force your local dev DB to sync up with the appropriate branch. If you try that and you still get issues my guess is it's a bug - but try it first. In general my advice is that wherever possible you to maintain a separate database for each branch. If branching is something you do regularly this will force you to get better at provisioning, which will have many nice consequences. / comments
In this scenario your database will not change simply by switching branches. The changes might appear as a conflict in the get latest tab? If not try using SQL Compare after you switch branches to ...
What VCS are you using? Git? TFVC? etc. / comments
What VCS are you using? Git? TFVC? etc.
Yes - that's a better idea. Do what David said. / comments
Yes - that's a better idea.Do what David said.
Nope - but you could write a tSQLt test for it and run it as part of your build/CI processes. / comments
Nope - but you could write a tSQLt test for it and run it as part of your build/CI processes.
Generally you want to install it on a separate machine that can talk to the SQL Server. You don't want to let DLM Automation hog the prod SQL Servers CPU and memory. Also, you can potentially just configure one deployment machine for multiple targets. Might help with all the firewall-foo. / comments
Generally you want to install it on a separate machine that can talk to the SQL Server.You don't want to let DLM Automation hog the prod SQL Servers CPU and memory. Also, you can potentially just c...