Comments
Sort by recent activity
The way it works behind the scenes is documented here: https://documentation.red-gate.com/soc6/reference-information/how-sql-source-control-works-behind-the-scenes If this was a fresh link to source control I normally see it come up as a conflict, since SQL Source Control does not know whether the source control or database version is the most up to date. / comments
The way it works behind the scenes is documented here:https://documentation.red-gate.com/soc6/reference-information/how-sql-source-control-works-behind-the-scenesIf this was a fresh link to source ...
You've already found the page to download old versions, but you are right - DLM Automation v2 doesn't seem to be there. If you want the latest version you should instead be looking for SQL Change Automation. It was renamed a few months ago. More info here: https://documentation.red-gate.com/display/SCA3/DLM+Automation+licenses+and+SQL+Change+Automation / comments
You've already found the page to download old versions, but you are right - DLM Automation v2 doesn't seem to be there.If you want the latest version you should instead be looking for SQL Change Au...
This is typically a much bigger problem than just buying a tool - it's how you use it. Yes, in some cases you need to write the scripts to deliberately work around some specific scenarios - this could either be handled using pre- and post-deploys or switching to a migration based source control solution, such as SQL Change Automation. (I mean by using the VS extension that was formerly called ReadyRoll INSTEAD of SQL Source Control. You will still use SQL Change Automation for deployment in either case. Redgate recently renamed stuff and now it's way harder to explain this.) Generally, however, downtime is caused because of dependencies between different systems that need to be upgraded at the same time and the system cannot run while some parts have been deployed and others have not. In that case you should look at the 'expand-contract' pattern and consider the wider reaching implications for the way your teams work together and co-ordinate your deployments. You may find these resources valuable: https://martinfowler.com/bliki/ParallelChange.html https://medium.com/continuousdelivery/expand-contract-pattern-and-continuous-delivery-of-databases-4cfa00c23d2e Apologies in advance - this isn't easy. / comments
This is typically a much bigger problem than just buying a tool - it's how you use it.Yes, in some cases you need to write the scripts to deliberately work around some specific scenarios - this cou...
I'll let the (current) Redgate folks respond to the support issue since I don't work there any more. / comments
I'll let the (current) Redgate folks respond to the support issue since I don't work there any more.
So how SoC* works out what should go into the commit vs the get latest tab is explained here: https://documentation.red-gate.com/soc6/reference-information/how-sql-source-control-works-behind-the-scenes (*Sorry, SSC means SqlServerCentral to most Redgate and ex-Redgate folks. SC is SQL Compare. SoC is SQL Source Control. No reason you would know that but it's a habbit that's hard for me to break!) Clearly in your case for some reason SoC has failed to work out whether the change was changed by someone else in source control and needs to be added to your database (Get Latest) or removed by you on the DB and a needs to be deleted in source control (Commit). That's why it shows up in the wrong tab. Removing it from your local repo manually should flush out the issue... I hope. Yes, you can use SQL Compare to diff the DB vs the files and deploy the DB version into the files. Then you would need to do the git add and commit manually as in my prior comment or through VS Code, rather than through SoC. / comments
So how SoC* works out what should go into the commit vs the get latest tab is explained here:https://documentation.red-gate.com/soc6/reference-information/how-sql-source-control-works-behind-the-sc...
Out of curiosity, does it erroneously show up in the Get Latest tab? You could try hand cranking it in raw git. Delete the stubborn file in the local git repo manually. Then, from the appropriate directory in the command prompt: > git status (to review your changes) Then: > git add . (Stages all manual file changes for commit. Alternatively you could specify specific changes.) > git commit -m "your message" (Commits the change locally) Then go back into SSMS/SQL Source Control and verify whether everything has sorted itself out. / comments
Out of curiosity, does it erroneously show up in the Get Latest tab?You could try hand cranking it in raw git.Delete the stubborn file in the local git repo manually.Then, from the appropriate dire...
That's one of the primary reasons you should buy support and upgrades. The folks at Redgate invest quite a lot of money in updating the tools to support the latest versions. They need to fund that investment somehow. If you only want to use the tools in the short to medium term and are happy with the existing functionality don't buy support and upgrades. However, if you want to benefit from Redgate's ongoing investment to support the latest and greatest new features you should buy support and upgrades. Alternatively, you can choose not to renew and pay to upgrade it in the future. I've not worked in RG sales for a few years, but when I was a Redgate sales person it was deliberately priced so that renewing every year would almost always work out the most cost effective. / comments
That's one of the primary reasons you should buy support and upgrades. The folks at Redgate invest quite a lot of money in updating the tools to support the latest versions. They need to fund that ...
It's worth taking a look at the specs of your build agent. Often TeamCity build agents run on cheap hardware because compiling .NET code isn't particularly resource intensive. Running a DB build is quite different. Does it take a similar amount of time to run a build on your local machine? You can test this out by running the build manually using PowerShell. (See example 3 at the bottom of these docs: https://documentation.red-gate.com/sca3/reference/powershell-cmdlets/sync-databaseschema) / comments
It's worth taking a look at the specs of your build agent.Often TeamCity build agents run on cheap hardware because compiling .NET code isn't particularly resource intensive. Running a DB build is ...
You can probably do it the other way around if you desperately want to - but I don't believe Redgate officially support it and wouldn't recommend it. If you *really* want to be able to use both a solution with a Visual Studio SSDT Database Project and SQL Source Control on the same project create the SSDT project in Visual Studio first to generate your .sln file, then connect with SQL Source Control (which simply wants a set of .sql files and isn't picky about folder structure). That said - you are likely to hit issues.
SQL Source Control might put SQL files in odd locations.
SQL Source Control won't have built in support for various SSDT features, such as SQLCMD variables or partial projects.
Since this is not officially supported by either Redgate or Microsoft I would expect a few dragons lurking in the details and neither party would be willing to commit to avoid making breaking changes in the future.
If you really want to work in Visual Studio I would recommend either sticking with SSDT or using Redgate's SQL Change Automation Visual Studio extension (formerly known as ReadyRoll). However, the Redgate Visual Studio extension works differently (some would say better) than either Redgate SQL Source Control or SSDT so I would do a little research first. Alternatively, if you really like SQL Source Control, use that exclusively and don't try to integrate it with an SSDT project. As I said, you probably could create a hybrid SQL Source Control/SSDT project if you really wanted to - just please don't. / comments
You can probably do it the other way around if you desperately want to - but I don't believe Redgate officially support it and wouldn't recommend it.If you *really* want to be able to use both a so...
What sort of source control repository are you using? (e.g. Git, TFS, SVN?) It's probably best to use the tools provided by the underlying source control technology to find this information. / comments
What sort of source control repository are you using? (e.g. Git, TFS, SVN?)It's probably best to use the tools provided by the underlying source control technology to find this information.