It would be very useful if it was possible to see which revision number was last deployed to a database. Source Control 4 used to update the extended properties after deployment but version 5 no longer does this.

Not knowing the revision number makes it difficult to bring a Live db up to the same revision as a UAT db, and ensuring the required migration scripts also get executed on the Live db.

Any change this could be added somewhere? Extended properties seemed a good place to save it.

I'm linking to an existing database using a local folder. The database is linked in shared mode.

The local folder was built by SSDT and contains a .sqlproj file. I'm notified of the beta functionality when linking, so I know SQL Source Control identifies the project as linking to SSDT.

When I add a stored procedure, the resulting script starts with:
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_NULLS ON
GO

These statements don't compile in SSDT. The first statement in each script must be a create statement.

I had removed these lines from the statement that I ran against SQL Server to create the procedure initially. After performing a commit, those statements are added in the resulting .sql script file.

I checked the stored procedure using OBJECT_DEFINITION(object_id) and find that those SET statements are not in the definition on the server. This indicates that SQL Source Control is adding those lines to the script.

Please enable a way to prevent adding those lines. SSDT raises SQL70001 errors "The statement is not recognized in this context" as a result of those statements.

Sorry if this is a duplicate request.

I'm linking to an existing database using a local folder. The database is linked in shared mode.

The local folder was built by SSDT and contains a .sqlproj file. I'm notified of the beta functionality when linking, so I know SQL Source Control identifies the project as linking to SSDT.

When I add a stored procedure, the resulting script starts with:
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_NULLS ON
GO

These statements don't compile in SSDT. The first statement in each script must be a create statement.

I had removed these lines from the statement that I ran against SQL Server…

Currently there is an option to edit migration scripts however edits will not get applied to other environments if the old version of the script was already run.

Imagine the scenario where a migration script is created to update one record in a table that does not have it's data versioned. The script is checked in and deployed to the CI environment and the QA (test) environment. QA test finds that the update was incorrect. Development edits the migration script to correct it. The edited script will not get run again on those environments.

Currently there are only two work arounds we are aware of. Create a second migration script and leave the original incorrect one, both to be run in production. Or, manually go in to the [RedGateLocal].[DeploymentMetadata] and delete the rows that mark the script deployed.

We would like to see a checkbox or similar feature to mark an edited migration script to be run again, even though the original version had already been run on some environments.

Currently there is an option to edit migration scripts however edits will not get applied to other environments if the old version of the script was already run.

Imagine the scenario where a migration script is created to update one record in a table that does not have it's data versioned. The script is checked in and deployed to the CI environment and the QA (test) environment. QA test finds that the update was incorrect. Development edits the migration script to correct it. The edited script will not get run again on those environments.

When using V3 of migrations, SQL Source control parses the migration script, finds all dependent objects, and makes sure that the AutomaticSchemaChange.patch file brings the database up to a state where the user-written migration script can run. But, sometimes the AutomaticSchemaChange.patch file has a bug in it, due to a bug in the SQL Compare engine. I can file a bug on this, but those bugs don't seem to get fixed very quickly, and without a fix I can't deploy my database.

The only workaround that I've found in this case is to manually edit the AutomaticSchemaChange.patch file to fix the bug. But, this file is incredibly hard to edit. It's in "git patch" format, and if just one character is wrong, the migration script process will crash. It's even critical that the line endings be exactly right (some must be newlines, some must be carriage-return newline combinations.

The current approach used in the AutomaticSchemaChange.patch makes it very hard to work around any issues or errors. Perhaps you could find a more user-friendly approach for the inevitable cases where the tools have bugs and need to be hand tweaked.

When using V3 of migrations, SQL Source control parses the migration script, finds all dependent objects, and makes sure that the AutomaticSchemaChange.patch file brings the database up to a state where the user-written migration script can run. But, sometimes the AutomaticSchemaChange.patch file has a bug in it, due to a bug in the SQL Compare engine. I can file a bug on this, but those bugs don't seem to get fixed very quickly, and without a fix I can't deploy my database.

The only workaround that I've found in this case is to manually edit the AutomaticSchemaChange.patch file to fix…

From the commit dialog I can see the changes that have occurred and decide whether to commit or not. Then after committing I could generate a script covering those amendments. It appears that you have removed this functionality. Now under Migrations I just get a list of objects with changes and have no idea what has changed and just have to blindly generate a migration script or flick back and forth between the Commit tab and Migrations tab to determine what to include.
Maybe I have missed something - only been trying for a day!

I would like to be able to pause/start scanning a database for changes as will. It is trying to do several at the same time right now and one of them is huge which is taking longer than it should. If I could only scan the one I am working with at the moment it would save me time system resources.

On one of our databases we have a lot of changes we don't want to commit at the moment, it would be great to have UI filter on commit tab so we can easily find one of the changed procedures/tables/functions by schema/name and select it for committing.

This more a bug report than a feature suggestion. When i start Microsoft SQL Server Management Studio 10.50.2500.0 the fontsize is fine. But as soon as redgate loads the font size are changed.
See here: https://stackoverflow.com/questions/40207918

This is caused by the SQL Compare parser not understanding this syntax. The good news is the SQL Compare team are currently working on SQL Server 2016 parser support. Once this work is done and SQL Source Control is updated with the latest SQL Compare engine, I will update this request again.

When committing changes it would be nice to be able to mark changed items as "Covered / Included in existing migration script" so that they are not checked into source control. I am specifically talking about uncommitted schema changes. For example, transferring a table to a different schema. SQL Source Control sees this as a drop (from old schema) and create (in new schema), but there are times when it should be an ALTER SCHEMA statement in order not to lose the data from the table. The ALTER SCHEMA can be added to an existing migration script instead of creating a new migration script in the "Replace uncommitted schema changes" section on the Migrations tab. Then on the Commit tab you could select the drop and create rows and mark them as covered by the migration so that they don't get checked in or deployed.

When committing changes it would be nice to be able to mark changed items as "Covered / Included in existing migration script" so that they are not checked into source control. I am specifically talking about uncommitted schema changes. For example, transferring a table to a different schema. SQL Source Control sees this as a drop (from old schema) and create (in new schema), but there are times when it should be an ALTER SCHEMA statement in order not to lose the data from the table. The ALTER SCHEMA can be added to an existing migration script instead of creating…

If you have a HiDPI or 4K display, SSMS is scaled to 2x. In SQL Source Control, The Commit and Get Latest tabs are fine, but the Migrations, Locking and Setup UI are scaled MUCH larger than 2x. I would prefer those UIs be scaled to 2x.

If I exclude items from source control they should not default to be committed due to dependencies. It would be great if there was a setting when items are excluded to never include them in the list of items that are dependencies.

Get rid of the option for anybody to unlock an object, but instead allow to unlock only by the person that locked the object or by a group in group role in the database where only few people have access.