A lot of people agree with you. The following is a link to a similar suggestion with quite a few votes.

_http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/462220-don-t-refresh-the-commit-get-latest-automatically

A checkbox option to enable/disable the auto refresh with a manual refresh button next to it would suffice.

I find myself double checking other documents and SQL screens to make sure I'm good to go for a commit and it's annoying that the screen auto refreshes when I know nothing pertaining to my checkin has changed.

This is a absolute must. We commit our changes associating them with a TFS work item. Having to commit certain changes to a work item and then wait for a refresh before commiting further changes to another work item is really time consuming and not required.
Having the ability to manually refesh the page following several commits would be a huge advantage.

Even with the SQL Source Control tab closed, a compare is performed every time that I select a database. (This is indicated by the gray gumball turning green and spinning...) On some of our larger databases, this can take up to an hour to complete. We have 10 dbas accessing a box. Every time that they single click on a db name in SSMS, a compare is going to fire off. This creates way too much overhead for this tool to be completely implemented. I love the end result though. Lets just add a "Compare" button instead of the auto-check.

"Stephanie (Admin, Red Gate) commented · March 19, 2010 09:17 · Flag as inappropriate · Delete
For now, you could close the SQL Source Control tab when you don't need it. You can click "x" when the tab is focused or you can right-click on it and select "hide." Then, when you want to Commit or Get Latest, just right-click on the linked db and select this option. This will open the SQL Source Control tab and perform just the behaviour you selected in the list. After committing/getting, remember to close the tab again so it doesn't refresh every time it comes into focus. "

I am curious to see how this was done:

"philcart commented · July 29, 2012 17:50 · A lot of the requests for manual refresh stem from the fact that SSC is so slow in doing the refresh. Myself, I've updated the config file to refresh manually, just for that reason."

Could you possibly post how you updated the config file?

Thank you for re-opening this Chris.
We would very much like to have the ability to turn off automatic refreshing. This is especially important to us when we commit many objects at once and need to go back and forth between SSMS windows, while deciding what should be checked-in now and what later etc... having to wait for a refresh each time is not very pretty.
It's also worth mentioning here, that we have submitted another issue separately that each time we come back to the commit/get latest (after the refresh is done) it loses the selections. This just adds to the frustration and we'd really like to see that fixed.

Thanks again for all your patients with us
Shmuel

@David - Using 3.0.13.4178, this is quicker than prior versions. The nice commit page is a little bit of a waste as it's not seen as much now.

I guess the "slowness" is more a perception thing than anything else. The constant scripting of objects for comparison during the commit/get latest process doesn't help.

For the undo,
- open Commit tab
- watch progress go through 1/4 -> 4/4
- select the items I want to undo
- right-click and choose Undo Changes...
- look at new dialog that says "4/4 calculating changes" (surely there is nothing more to calculate)
- select the item I want to undo
- click "Undo Changes"
- watch another dialog that seems to go through the same steps again.

Would also be good to see a lot of this stuff done in the background as well. So we don't see the 1/4 -> 4/4 steps at all. When we open the commit/get latest tabs they already has the information there. Background processing would also allow some context switching without interrupting the SSC processing.

I sit more in the DBA\Developer role and as such am constantly connected to more than 2-3 servers, doing dev work and maybe checking a production data issue. When I'm working on a development item in database A, I go to the commit tab, refresh, then switch to a different server to check some other unrelated issue (maybe production data issue), switch back to commit tab and have to go through the whole refresh process again. This becomes very annoying and counter-productive as I can't do anything else while I'm waiting for SSC to complete it's work.

Another one, would like to be able to have multiple instances of SSC open so I can work on different development server/databases. Given that each database has it's own SSC workspace, why can't I have multiple instances of SSC open?

Cheers
Phil

@Phil - could you tell us which version of SQL Source Control you're using? Also, you gave an example of the undo being slow. Are there any other examples that you'd like to bring to our attention?

A lot of the requests for manual refresh stem from the fact that SSC is so slow in doing the refresh. Myself, I've updated the config file to refresh manually, just for that reason.

I still think that the comparison process is overly complicated and is duplicated in a couple of steps and this leads to the lengthy delays on even a small database.

eg: when I want undo a change to an object, I select the object and watch as it works out what objects to undo, instead of just undoing what I've selected.

I'm guessing that the majority of users know what they're doing, but SSC is trying to account for the small percentage of users that don't know what they're doing so want the tool to do everything for them.

SSC as a product, and Red-Gate by association, has lost a lot of ground in my company because it's lack of speed, and lack of background processing is seen to actually hinder our development process. It's especially relevant when I get asked about the performance by the CIO when I put forward a bill for renewing the maintenance contract.

Please get some devs on this and lets see some real progress.

Thanks
Phil

Would also be great if a warning was shown if the result was not "up to date" (=different from if you ran a refresh) . This check shold be run in the background so you don't have to wait for it to complete.

Hi

We've re-opened this 'idea' following your feedback.

Some of you would prefer the commit/get latest refresh process to always be manually initiated, rather than the conditional refresh we have implemented in SQL Source Control.

Please vote for this idea if you would rather have complete control over the refresh of commit and get latest tabs.

Thanks,
Chris

This is GOOD, but I expected more:
The selection of objects you made should not be changed when you return!
Let me explain with an example:
When moving objects from development to acceptance test we link the Test db to the Dev.branch. Then we walk through the GetLatest list and select which objects to move to the test db. During this work we often need to open other objects (related) and look at the code. After opening another tab and switch back to SC tab all checkbox are back to default...
OK, we can have another instance of SSMS or have another tab group to do this, but we often do this work in a group and using a projector, so this becomes a bit "messy"...

or maybe we are not working as expected with the branches?
We had not found a convienient way to move between branches in TFS with full control of every object...

This is largely due to the slow performance of SQL Source Control. I should be able to fire it off, then work on other tabs for a while, then come back to review the results, just like my web browser. It's a major pain to have it recalculate every time I visit the tab. What am I to do? Go have a coffee while my machine sits there useless while it chugs through processing just because it cant process in the background? Major bugbear.

It would also be great if the refresh could happen in the background so I can do work in another tab while the refresh is chugging along.

I have a tendency to switch between tabs a lot in SSMS, several script windows open, etc. during development. It would definitely save processing time and be less annoying if I could generate/refresh the differences on demand.

+1 ! This is very annoying! What is the refresh button good for, if each tab click goes through the long running refresh cycle?

We should be offered an option to refresh when the SQL Source Control tab gets focus again. This is very frustrating.

For now, you could close the SQL Source Control tab when you don't need it. You can click "x" when the tab is focused or you can right-click on it and select "hide." Then, when you want to Commit or Get Latest, just right-click on the linked db and select this option. This will open the SQL Source Control tab and perform just the behaviour you selected in the list. After committing/getting, remember to close the tab again so it doesn't refresh every time it comes into focus.

We are looking into making performance improvements to help with this refresh behaviour.

Yes. This is an issue for me too with databases containing ~1000 objects. I want to see what is in the database and only let svn get involved when I try and commit a change. This is how svn works anyway. I shouldn't be able to commit unless I have first updated any changes.

I agree as well and it's not just when the source control tab is open, the SQL traffic generated by red gate is considerable, perhaps not a performance concern but I'm curious if this could be reduced. Just run profiler for a bit to see. expand the database node in SSMS and single click on a database that's in source control, the more databases you click the more traffic, the individual databases don't need to be expanded and the source control window does not need to be open. I saw about a 1000 select statements run in a few minutes after clicking on a half dozen databases. Once the gumballs went away the activity continued about 1000 selects every few minutes.