Comments
Sort by recent activity
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...
Perhaps I'm misunderstanding something? If versioning of data is not a requirement, why is your repo so big? It sounded like you were putting a lot of data into source control. / comments
Perhaps I'm misunderstanding something?If versioning of data is not a requirement, why is your repo so big? It sounded like you were putting a lot of data into source control.
Yeah - try not to put that much data in source control. With that much data I'd be thinking about alternative ways to track the data in the larger tables. / comments
Yeah - try not to put that much data in source control.With that much data I'd be thinking about alternative ways to track the data in the larger tables.
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>===================================================================...