Comments
Sort by recent activity
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...
Hi
Thanks for your question. Can I ask why you perform a 'switch'? Is it in connection with branching your database?
If so, we are currently considering ways for SQL Source Control to better support workflows where users want to branch regularly.
It would really help if you could you explain the workflow you go through when you 'switch', and then we can endeavour to take this into account when we design the new feature.
Best regards
Chris / comments
Hi
Thanks for your question. Can I ask why you perform a 'switch'? Is it in connection with branching your database?
If so, we are currently considering ways for SQL Source Control to better suppor...
Hi
You should be able to rollback static data using Red Gate's SQL Data Compare - if you have a license for this product. You will need to populate a scripts folder with the the schema and data changes you want to rollback to and then deploy that back to your development database. You could then commit the changes in SQL Source Control to effectively rollback the data.
SQL Data Compare v10.0 will be realeased in the next few weeks that will enable a new button on the SQL Source Control v3.0's History Dialog allowing you to rollback static data to a selected version.
Best regards
Chris / comments
Hi
You should be able to rollback static data using Red Gate's SQL Data Compare - if you have a license for this product. You will need to populate a scripts folder with the the schema and data ch...
Hi
You are able to reduce the frequency of SQL Source Control's database polling by setting an option in a confirguration file. For information see - http://www.red-gate.com/MessageBoard/vi ... hp?t=12837.
Best regards,
Chris / comments
Hi
You are able to reduce the frequency of SQL Source Control's database polling by setting an option in a confirguration file. For information see - http://www.red-gate.com/MessageBoard/vi ... hp?...
If you unlink and relink the object history will not be lost. This is all stored in your version control repository.
By unlinking and relinking to the same repository location you are just making a new local working base for SQL Source Control to interact with.
Best regards,
Chris / comments
If you unlink and relink the object history will not be lost. This is all stored in your version control repository.
By unlinking and relinking to the same repository location you are just making a...