Comments
Sort by recent activity
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.
I implemented a solution that mightmwork for you in part 3 of this series: https://www.red-gate.com/hub/product-learning/sql-compare/how-to-build-multiple-database-versions-from-the-same-source-using-sql-compare-filters That solution used a migrations approach to script out the tables that varied per target, but you could do the same for data. However, a simpler way might be to use the default SQL Source Control functionality to store a "master" static data set, and then manually create copies of the master data set in different directory in source control (away from the SQL Source Control directory) with a copy that you manually update with the data for CustomerA and CustomerB etc. Then your build process can run some PowerShell or something to sub the "master data" with the "CustomerA data" etc before running your SQL Change Automation build and deployment processes. / comments
I implemented a solution that mightmwork for you in part 3 of this series:https://www.red-gate.com/hub/product-learning/sql-compare/how-to-build-multiple-database-versions-from-the-same-source-usin...
Jonathan Hickford covered a similar scenario in this blog post. I hope it helps: https://www.red-gate.com/blog/database-development/customer-specific-database-deployments / comments
Jonathan Hickford covered a similar scenario in this blog post. I hope it helps:https://www.red-gate.com/blog/database-development/customer-specific-database-deployments
Idera might do it? I'm not sure though so please take that with a pinch of salt. / comments
Idera might do it? I'm not sure though so please take that with a pinch of salt.
I'm aware that there are some other tools that can do this, but either never used them. I know MSSQL>ORACLE is more challenging than MSSQL>MSQL or ORACLE>ORACLE, and hence your mileage may vary. I'm afraid I couldn't do much more than Google it for you. But I wish you the best of luck. / comments
I'm aware that there are some other tools that can do this, but either never used them. I know MSSQL>ORACLE is more challenging than MSSQL>MSQL or ORACLE>ORACLE, and hence your mileage may vary.I'm...
No. / comments
No.
I'm not sure I understand exactly. The default functionality is that SQL Source Control/Compare/SQL Change Automation will deploy the schema but not the data. So data in the target database will be safe. Now, in some scenarios SQL Compare might not know how to do this. Table renames are the obvious example - SQL Compare has a tendency to interpret that as a drop and create - and the data gets blown away. With this in mind, make sure you are aware of any warnings about potential data loss. To get around the data loss either use "migration scripts" in SQL Source Control or revert to a manual deployment on this occasion if SQL Compare cannot handle it. Alternatively switch to using the SQL Change Automation Visual Studio plug-in (previously known as ReadyRoll). Generally, if this is only a rare issue I'd stick with SQL Source Control, but if this is a regular problem it may make sense to switch to SQL Change Automation. / comments
I'm not sure I understand exactly.The default functionality is that SQL Source Control/Compare/SQL Change Automation will deploy the schema but not the data. So data in the target database will be ...
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,...