Comments
Sort by recent activity
Hi
We’ve recently added a configuration file option to allow users to turn off Data Comparisons in SQL Source Control. This is available in the latest version that you can get by going to the Check For Updates item on SQL Source Control's Help menu.
To turn data comparisons off you need to do the following:
1. Close SSMS.
2. Open the following file - C:\Users\[username]\AppData\Local\Red Gate\SQL Source Control 3\ RedGate_SQLSourceControl_Engine_EngineOptions.xml
3. Add the following IgnoreDataDirectory tag inside the EngineOpions tag:
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<!---->
<EngineOptions version="2" type="EngineOptions"> <IgnoreDataDirectory>true</IgnoreDataDirectory>
</EngineOptions>
4. Save file and restart SSMS.
Of course, you will have to change the 'IgnoreDataDirectory' value to be 'false' if you want to start comparing Data again.
Please let me know if this process works ok for you - and if you would like to see this option added to the user interface somewhere.
Best regards,
Chris / comments
Hi
We’ve recently added a configuration file option to allow users to turn off Data Comparisons in SQL Source Control. This is available in the latest version that you can get by going to the Ch...
Hi
I believe there was a logging bug in that version of the product that we have subsequently fixed. Can you please download the latest version via the Check For Updates option in the SQL Source Control Help menu?
If the problem still occurs, please contact support@red-gate.com and we will do what we can to resolve the issue.
Best regards,
Chris / comments
Hi
I believe there was a logging bug in that version of the product that we have subsequently fixed. Can you please download the latest version via the Check For Updates option in the SQL Source C...
Hi,
Thanks for your question - Yes, there is a way to configure SQL Source Control to ignore user permission differences [image]
Please see the following post that details how to set the comparison options that SQL Source Control uses when comparing databases to version control: http://www.red-gate.com/MessageBoard/vi ... hp?t=14278
Using the mechanism specified there, you should be able to set the option for "Ignore users' permissions and role memberships".
Please let us know if you need any further help with this.
Best regards, / comments
Hi,
Thanks for your question - Yes, there is a way to configure SQL Source Control to ignore user permission differences
Please see the following post that details how to set the comparison optio...
Hi
We believe we have fixed the problem and hope to release before the end of next week.
Best regards,
Chris / comments
Hi
We believe we have fixed the problem and hope to release before the end of next week.
Best regards,
Chris
Hi
Just to clarify, your developers have a local dedicated copy of each customer database (with varying levels of 'cruft') that they are making changes to and they are committing changes made on all these customer databases into one SVN repository.
The problem is that they might accidently commit some of the cruft on any one of the customer databases. This will be committed to the shared SVN repository and the cruft will be automatically deployed to all the other customer databases.
If this is the case, I have a couple of suggestions (which you have probably tried and rejected):
1. Set-up a filter in SQL Source Controlfor each customer database that hides all the cruft. It can be committed and shared by all your developers - stopping it from appearing in anyones commit list.
2. Create a db script which drops all the cruft and pass it to each developer to run on their local databases. They will then never see the cruft in the commit list the dbs should now synch with the schema in SVN.
3. Let the developers commit all the cruft into SVN but add a filter to SQL Compare to avoid it being deployed.
I hope this helps, please let me know if I have not understood the problem.
Best regards,
Chris / comments
Hi
Just to clarify, your developers have a local dedicated copy of each customer database (with varying levels of 'cruft') that they are making changes to and they are committing changes made on al...
Hi
Thanks for that. I've got a few more questions to clarify what's happening:
1. Can I confirm that you are using SQL Compare to deploy your schema changes rather than SQL Data Compare to deloy static data changes?
They are two distinct products and SQL Compare will not try to compare data changes.
2. When you unlinked the static data tables, did you commit that change to SQL Source Control? As the unlink operation should appear in the commit tab.
3. Are you making a change to the schema for the static lookup table that has showed up when doing your initial comparison? If so, is it possible this change could cause data loss?
Thanks,
Chris / comments
Hi
Thanks for that. I've got a few more questions to clarify what's happening:
1. Can I confirm that you are using SQL Compare to deploy your schema changes rather than SQL Data Compare to deloy s...
Hi
Looking at the records for a similar problem, I think this may have been solved in a later version of Data Compare.
Can you upgrade to the latest version of Data Compare v9? I believe its full version number 9.1.0.365 and you should be able to get it from here: ftp://support.red-gate.com/patches/SQL_ ... .0.464.zip
Best regards,
Chris / comments
Hi
Looking at the records for a similar problem, I think this may have been solved in a later version of Data Compare.
Can you upgrade to the latest version of Data Compare v9? I believe its full v...
Hi
I think the issue you describe is the same as this one. The conclusion was that we did not think the failure to update RedGateDatabaseInfo.xml would cause a problem. However, you have found this is not ther case.
What version of SQL Data Compare you are using? As we believe the latest version should not exhibit that behaviour (although the RedGateDatabaseInfo.xml will still not be updated by SQL Source Control).
Best regards,
Chris / comments
Hi
I think the issue you describe is the same as this one. The conclusion was that we did not think the failure to update RedGateDatabaseInfo.xml would cause a problem. However, you have found thi...
Hi John,
Thanks for adding your thoughts to UserVoice. I will post status updates on those entries if/when we start to work on those ideas.
I think it is likely that we will add the 'red marker to databases in the Object Explorer that contain unretrieved changes' feature at some point in the future.
I'm glad that the shared filters and static data links help.
Best regards,
Chris / comments
Hi John,
Thanks for adding your thoughts to UserVoice. I will post status updates on those entries if/when we start to work on those ideas.
I think it is likely that we will add the 'red marker to...
Hi
Currently there is no command-line interface or API for SQL Source Control. However, we do plan to introduce a feature where developers are 'auto-linked' to a database that they have connected to in SSMS and has already been added to a version control respository via SQL Source Control.
Can I ask how each of your developers creates their local development database? Do they use a recent backup of a production database?
You are correct that filters are shared between users as they are stored in the repository. This is also true of static data table links - once you set them up all other developers that connect to that repository should also have those connected.
We have not considered a "Get Latest on all connected databases" feature - either automated or via a button click. We have thought about adding a red marker to databases in the Object Explorer that contain unretrieved changes. This is similar to how the blue markers currently indicate local changes that the user needs to commit. Would that help?
It'd be great if you could vote on this idea on our feedback siteif you'd like to see these indicators - or create a new suggestionfor your "Auto Get Latest" idea.
Best regards,
Chris / comments
Hi
Currently there is no command-line interface or API for SQL Source Control. However, we do plan to introduce a feature where developers are 'auto-linked' to a database that they have connected t...