Comments
Sort by recent activity
There are a couple of things you could do to get around this issue. Neither are perfect, but they should work. 1. Move to a migrations based approach. If your developers use a SQL Change Automation project, rather than a SQL Source Control project, the deployments will be based on scripts that were curated by the developers so you would avoid unexpected column drops. 2. Move to a master == production branching strategy, and set up a process to detect and automatically add changes made in production directly to master. If this ever fails, you will get a broken build to alert you to an issue. All development changes would need to be done on a branch and merged with master when they are ready to be deployed. Obviously these are both avoiding the issue rather than fixing it. In an ideal world the 3rd party product updates would be going through source control too. / comments
There are a couple of things you could do to get around this issue. Neither are perfect, but they should work.1. Move to a migrations based approach. If your developers use a SQL Change Automation ...
How about this? Master = Production. Dev work is done on feature branches on development databases. (Ideally separate databases per feature/developer. Have you looked at SQL Provision?) On demand, plus on a periodic basis (e.g. at the weekend/at end of sprint) the following is automated: From your post above: 1) restore latest prod on the dev server as <DB>_FROM_PROD_<yyyMMdd_hhmmss> 2) rename the dev <DB> to <DB>_OLD 3) rename the <DB>_FROM_PROD_<yyyMMdd_hhmmss> db as <DB> My additions: 4) <DB> is compared with master in source control, any updates are automatically committed as "DRIFT CORRECTION". This should get all 3rd party and other updates on prod into master. When this occurs you may want to trigger some sort of notification to your team so they can review the updates. 5) master is automatically merged with all branches. If this merges nicely, wonderful, your development changes do not conflict with production drift. If this causes a merge conflict/build error, your developers need to review the problem before they can push to production. To release code to production: 1) Automatic check that production and master are in sync. If not, abort with a drift warning. Resolve drift by updating master and try again. 2) Master is merged into feature branch to ensure there are no merge conflicts. 3) Any automated tests are run to verify the merged code. (If you don't have tests, write some.) 4) Feature branch is merged into master. 5) Master is deployed to production. 6) Master is merged into any other feature branches. / comments
How about this?Master = Production.Dev work is done on feature branches on development databases. (Ideally separate databases per feature/developer. Have you looked at SQL Provision?)On demand, plu...
There isn't a rollback migration feature. If it was me, I'd kill and respawn my database each time I switched branches. If you care about data, SQL Clone is your answer. / comments
There isn't a rollback migration feature.If it was me, I'd kill and respawn my database each time I switched branches.If you care about data, SQL Clone is your answer.
It doesn't. This is both a good thing and a bad thing. For example, SSDT gives you great build output based on your cross-DB dependencies, but they also become almost impossible to manage. With the Redgate approach it is far easier to decouple your source control projects and work on them in manageable chunks. Then you can pickup on broken database dependencies by running your builds on an integration server instance. This still gives you the fast feedback, but enables far simpler database development. However, it comes with the cost of maintaining a persistent integration environment. Obviously, the ideal solution, is to work towards a more loosely coupled architectiure, avoiding direct dependencies between databases where possible. / comments
It doesn't.This is both a good thing and a bad thing. For example, SSDT gives you great build output based on your cross-DB dependencies, but they also become almost impossible to manage.With the R...
I suspect you only have a licence for SQL Compare Standard. Comparing against source control / scripts folders is a SQL Compare Pro feature. [image] https://www.red-gate.com/products/sql-development/sql-compare/ / comments
I suspect you only have a licence for SQL Compare Standard. Comparing against source control / scripts folders is a SQL Compare Pro feature.https://www.red-gate.com/products/sql-development/sql-com...
Does your git repo already have a remote configured? Assuming you followed this process - the push button should appear: 1. Create your remote repo 2. Clone remote repo locally 3. Link to local repo 4. Make some commits Now you should have a push button. However, if you have just done the following: 1. Created a local repo without a remote 2. Linked to S~QL Source Control 3. Made some commits In this scenario you will not see a push buttong because SQL Source Control does not know any information about your remote repo. Bottom line - you need to set up your remote repo outside of SQL Source Control. Once this is set up, SQL Source Control will be able to push to it. A test: Can you run the following from the command prompt?: C:/your/repo> git push If you can, and you have some commits locally that have not yet been pushed to the remote, SQL Source Control should display a push button in the "Commit" tab. However, if that command does not work, you should not expect SQL Source Control to work either. / comments
Does your git repo already have a remote configured?Assuming you followed this process - the push button should appear:1. Create your remote repo2. Clone remote repo locally3. Link to local repo4. ...
You probably can't do this using a SQL Compare project, but if you used the /Scripts1 switch instead this should probably work. So a few questions: 1. What is the use case? 2. Why do you want to use the project file instead of just pointing directly at the source code. 3. Why are the developer's tests not in source control? / comments
You probably can't do this using a SQL Compare project, but if you used the /Scripts1 switch instead this should probably work.So a few questions:1. What is the use case?2. Why do you want to use t...
In settings, there's an "under the hood" section. It should have the references to all your transient and working base repos. For more info on these: https://documentation.red-gate.com/soc/reference-information/how-sql-source-control-works-behind-the-scenes Assuming your developer does not have any work they are afraid to lose, have you tried making a note of the working base/transient locations, unlinking everything, deleting all working base / transients, and re-linking? / comments
In settings, there's an "under the hood" section. It should have the references to all your transient and working base repos. For more info on these:https://documentation.red-gate.com/soc/reference...
This would be awesome. :-) +1 / comments
This would be awesome. :-)+1
Am I reading it correctly, it literally only says: <div>SQL Data Compare Command Line for DLM Automation V13.8.0.12547
</div><div>==============================================================================</div><div>
Copyright Copyright c Red Gate Software Ltd 2019</div><div><br></div><div>
DLM Automation: in trial, expires 2019/09/26 05:17:58 +05:30</div><div>
Automation License: in trial, expires 2019/09/26 05:17:58 +05:30</div><div>
Registering databases</div>
That doesn't look right to me. I would have expected either some feedback about the results, or some error message. Unless the process was exited before it had finished? I've emailed the official Redgate support team and asked them to have a look at this thread. / comments
Am I reading it correctly, it literally only says:<div>SQL Data Compare Command Line for DLM Automation V13.8.0.12547
</div><div>===================================================================...