How can we help you today? How can we help you today?
AlexYates
Activity overview Badges (0) Posts (5) Comments (254)

Comments

Sort by recent activity
Fantastic to hear you got it working! By the way, whether or not you decide to adopt SCA projects, I highly encourage you to look at the SCA PowerShell cmdlets for executing your deployments with TeamCity, rather than SQLCompare.exe: https://documentation.red-gate.com/sca/reference/powershell-cmdlets There is even a TeamCity plug-in for them so you probably don't need to write any code yourself: https://documentation.red-gate.com/sca/deploying-database-changes/add-ons/teamcity Once you get it up and running, it's much easier to maintain your deployment pipelines and you'll start benefitting from all the new PowerShell stuff Redgate has been working on. Happy deployments! / comments
  1. Community
  2. SQL Compare
  3. SQL Compare scripts folder - rename a table
Fantastic to hear you got it working!By the way, whether or not you decide to adopt SCA projects, I highly encourage you to look at the SCA PowerShell cmdlets for executing your deployments with Te...
0 votes
Hi Viki, Migration scripts in SQL Source Control is deprecated: https://documentation.red-gate.com/soc/common-tasks/working-with-migration-scripts They were in theory a simple solution, but in practice they were hard to manage and troubleshoot. Redgate has since delivered a couple of better options that are more reliable. Instead of using migration scripts, you should look at one of these two solutions. Pre/Post deploy scripts https://documentation.red-gate.com/soc/common-tasks/working-with-pre-post-deployment-scripts Use a pre-deploy script to check whether the rename is required (pre/post deploy scripts need to be re-runnable) and, if so, sp_rename the table with a temporary name (to archive/protect the data) and recreate the original table (so the deploy script doesnt fail). Then use a post-deploy script to check if your temp table name exists and, if so, to tidy up. Then upgrade SQL Compare to v13.4.7 or later and SQL Compare will use you pre/post deploy scripts when it runs the update. SQL Change Automation (SCA) Redgate will advise you to start using SCA projects for deployments. You can learn more about that here: https://www.red-gate.com/hub/university/courses/sql-change-automation/sql-change-automation-2 SCA projects are primarily based on migration scripts, so you can override the default SQL Compare drop/create script with a simple sp_rename script in the source code. It's a really good solution but it would be a big change for you and you might need a new licence. (SCA requires full SQL Toolbelts for all developers.) There is a relatively new feature in SCA that allows you to use SQL Source Control for day to day development and then the SCA plugin for SSMS to convert your SQL Source Control projects into SCA projects when you want to release your updates. If neither of those solutions float your boat, I'm afraid the best option is to use SQL Compare to generate the script and then edit it and execute it manually. Alex / comments
  1. Community
  2. SQL Compare
  3. SQL Compare scripts folder - rename a table
Hi Viki,Migration scripts in SQL Source Control is deprecated:https://documentation.red-gate.com/soc/common-tasks/working-with-migration-scriptsThey were in theory a simple solution, but in practic...
0 votes
The short answer: No. SQL Source Control is opinionated about that being a conscious decision by a developer. The longer answer: Assuming your source control system has a half decent command line, you should be able to script it using the sqlcompare.exe command line (assuming you have an appropriate licence) and the CLI for your source control system. The process does a get a bit complicated though. SQL Compare can compare two versions of the code, but to do a "Get Latest" you need to do a three way comparison. (For mor info about why, read this: https://documentation.red-gate.com/soc/reference-information/how-sql-source-control-works-behind-the-scenes.) For this reason, I wouldn't do this lightly - it's more complicated than you think. I would also only do it if you were using a modern distributed source control system that handles branches elegantly. (Git.) If you are using git (or a similar dvcs) then you can use branches to avoid the three way comparison pain. If I was going to do it, I would save a script that does something a bit like the following into your repo, and then I'd use some scheduling tool to run it on a nightly basis on each of your developer's machines. > git status (Are there any commits that I need to pull down?) > if no updates, stop here. You are up to date already. Otherwise: > sqlcompare.exe (deploy any differences on local DB to branch) > git commit -m "auto updated from dev env at <timestamp>" > git pull > if merge conflict, error out. The developer has merge conflicts to fix in the morning > if no merge conflict: sqlcompare.exe to deploy source code to local dev DB For reference, this doesn't just do a "Get Latest", it also does a "Git Commit". If you want to avoid that you should review the documentation above and think about how to manually do a 3-way compare. On balance, I would be nervous about doing this. However, if you still wish to do it, I hope the information above helps. / comments
  1. Community
  2. SQL Source Control
  3. How do I AUTOMATE SQL Source Control to do a Get Latest of all dev databases nightly
The short answer:No. SQL Source Control is opinionated about that being a conscious decision by a developer.The longer answer:Assuming your source control system has a half decent command line, you...
0 votes
Howdy folks, Looking forward to tonight. See you all in a couple of hours! / comments
  1. Community
  2. Archived FoRG discussions
  3. Join the next FoRG virtual hangout: Tuesday 30 June
Howdy folks,Looking forward to tonight. See you all in a couple of hours!
0 votes
Sounds fun! Looking forward to it! :-) / comments
  1. Community
  2. Archived FoRG discussions
  3. Join the next FoRG virtual hangout: Tuesday 30 June
Sounds fun! Looking forward to it! :-)
0 votes
Put a timeout on your deploy process and treat this as an early warning that whatever change you just made might deserve special attention. Rebuilding a table and accidentally blowing away a clone is annoying, but relatively easy to fix. The main point is that it might one day save you from unexpectedly doing it on production. / comments
  1. Community
  2. SQL Clone
  3. clone for dev?
Put a timeout on your deploy process and treat this as an early warning that whatever change you just made might deserve special attention.Rebuilding a table and accidentally blowing away a clone i...
0 votes
Whatever bits you are changing on disk will be saved on the clone differencing disk. Hence, expect table recreations on big tables to have a proportional affect on the size of the clone. If a table is bigger than the available harddrive space, don't expect it to work. However, as long as you are not doing table rebuilds etc it should work fine. And as long as you treat source control as god and your clone as a disposable playground for dev/test. you shouldn't need to worry too much about the occasional clone breaking. If it does, respawn and try again. As for the anonymisation - that should work fine. You can either use the pre-anonymised version to create your source image or, if you have either a Redgate Masking Set or a plain T-SQL script to anonymise the data, you can use the production database/backup (backup recommended obvs) and run your masking script as part of the image creation. Don't try to run data anonymisation scripts on your clones. If you are masking a large amount of data your clones will grow proportionally large. Run your masking scripts on the source database or during image creation. / comments
  1. Community
  2. SQL Clone
  3. clone for dev?
Whatever bits you are changing on disk will be saved on the clone differencing disk. Hence, expect table recreations on big tables to have a proportional affect on the size of the clone. If a table...
0 votes
AppData\Local\Red Gate\SQL Source Control 7\LinkedDatabases.xml (Probably in C:\Users\Usrename\AppData) / comments
  1. Community
  2. SQL Source Control
  3. Where is the Instance\DB to local repo connection info stored?
AppData\Local\Red Gate\SQL Source Control 7\LinkedDatabases.xml(Probably in C:\Users\Usrename\AppData)
0 votes
https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility / comments
  1. Community
  2. SQL Source Control
  3. SQL Source control not functioning after most recent MSSSMS upgrade
https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility
0 votes
And this. More detail here: https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility / comments
  1. Community
  2. SQL Source Control
  3. Source Control and SQL Search - Not working after SSMS update
And this. More detail here:https://forum.red-gate.com/discussion/86731/ssms-18-5-compatibility
0 votes
Total activity
411
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
152