Comments
Sort by recent activity
It's a valid concern. Maybe someone from Redgate could chime in with ideas on how to prevent a disaster if the table was dropped or altered. After your fist deployment you could add a check to see if the table exists and has some rows before your deployment can happen. Depending on your situation though there may be valid cases where that table does not exist, like deploying to a new environment. / comments
It's a valid concern. Maybe someone from Redgate could chime in with ideas on how to prevent a disaster if the table was dropped or altered. After your fist deployment you could add a check to see ...
I refresh our lower environments all of the time from PROD and you want the _MigrationLog table to be refreshed as well so it also represents what has already been deployed to prod. / comments
I refresh our lower environments all of the time from PROD and you want the _MigrationLog table to be refreshed as well so it also represents what has already been deployed to prod.
"Mark it deployed" is for when the change is already made in DEV. You don't want it deployed again in DEV. It will still be deployed in other databases where its not set as deployed in the _MigrationLog table / comments
"Mark it deployed" is for when the change is already made in DEV. You don't want it deployed again in DEV. It will still be deployed in other databases where its not set as deployed in the _Migrat...
First part of your question Correct: 0 for baseline script and 1 for the change scripts 2nd part, DON'T DROP THAT TABLE, bad things will happen!!!! In all seriousness yes baseline should not get run again but your other migration scripts will run. You could code each migration script so that it could be re-run and not cause issues. For example have an if exists statement that checks if your change was already made. Another option might be to re-baseline. https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/advanced-project-manipulation/re-baselining But the best option is just don't drop that table [image] / comments
First part of your question Correct: 0 for baseline script and 1 for the change scripts2nd part, DON'T DROP THAT TABLE, bad things will happen!!!! In all seriousness yes baseline should not get ru...
Found this here: https://forum.red-gate.com/discussion/comment/154270#Comment_154270 So, _MigrationLog.Status column has the following meanings: 0 = migration was not deployed, e.g. a button "Mark as deployed" was clicked in the UI 1 = migration was deployed 2 = migration was imported to the project and no changes in the database were necessary. The most common scenario is when a developer makes some changes directly in the database, and then click the Refresh button in SCA VS, followed by an Import and Generate Script. / comments
Found this here: https://forum.red-gate.com/discussion/comment/154270#Comment_154270So, _MigrationLog.Status column has the following meanings:0 = migration was not deployed, e.g. a button "Mark as...
For migration scripts: https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/generating-scripts-to-capture-database-changes/migrations/script-status-information-window You don't need to manipulate the _MigrationLog table. The tool should be doing that. Click the button in VS for the scripts you do not want to run. Keep in mind though this only applies for that server / DB. In my example, see screen shot, when I deploy to UAT or PROD the script will still run. If you just want to add some scripts to your project that will never run with deployments see additional scripts. You would leave your scripts folder unchecked. https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/generating-scripts-to-capture-database-changes/programmable-objects/additional-scripts / comments
For migration scripts: https://documentation.red-gate.com/sca3/developing-databases-using-sql-change-automation/generating-scripts-to-capture-database-changes/migrations/script-status-information-w...
I just updated from 3.0.19052 to 3.0.19059 and I am NOT seeing this behavior. VS Enterprise 2017 15.9.3 It happens after you open the project or after you click refresh to check for DB changes? / comments
I just updated from 3.0.19052 to 3.0.19059 and I am NOT seeing this behavior. VS Enterprise 2017 15.9.3It happens after you open the project or after you click refresh to check for DB changes?
OK my project is only a few months old so it would not have any older readyroll stuff. Odd that the file is checked out but no changes made. / comments
OK my project is only a few months old so it would not have any older readyroll stuff. Odd that the file is checked out but no changes made.
Looks like this is now fixed with version 3.0.19066 - Thanks for the quick turn around! / comments
Looks like this is now fixed with version 3.0.19066 - Thanks for the quick turn around!
Here is an update from Redgate with the ticket I opened with support: This appears to happen due to whitespaces. The development team are currently investigating this (bug ref # SCA-2549) My response, I was able to get it working It is a bug with white space. I already have SyncOptionIgnoreWhiteSpace set to true in my project. I assume the bug is that the extension is not fully honoring that setting. I set SQL compare to not ignore white space and re compared my DEV and VS project. See screen shot.
I fixed my issue by running the migration script the extension generated on my DEV DB. The bug in the extension still needs to be fixed though. There was a white space difference with CR/LF
/ comments
Here is an update from Redgate with the ticket I opened with support:This appears to happen due to whitespaces. The development team are currently investigating this (bug ref # SCA-2549)My response...